How it Works
This article intend to be a system overview of this feature.
The entry point of the ACL feature is the SC declaration. As the vision claims to enable the SC to have extra capabilities, the first step is to declare inside the code block that an instance of ACL is required. Having the commented line // ACL as top-level code is mandatory to achieve this.
Input declaration and if(ACL) statements are also required inside the block body to properly use this API (see Syntax & Smart Contract requirements).
The system will resolve the if(ACL)statement and any instruction inside every time a request hits the storage endpoint, or any endpoint that results in a block (i.e., "storage," "block," "timestamp," "height"), the ACL runtime is triggered.
First, the node will find the original block where the current SC is declared. After checking the existence of the // ACL top comment in the case of SC declarations or in the parent SC when invocation calls, execution will proceed to create a shallow copy of the original returning block.
The copied block is now ready for a morphologic reconfiguration, where, in a sandboxed environment, it will safely execute itself, looking for the condition if (ACL) to see if exposes any errors or throw's exceptions.
Every exception will quit the sandboxed runtime returning a custom JSON value.
This sandboxed execution will input, as a JSON object payload, the request headers, query parameter fields, path, and JWT tokens provided in it. Last but not least, the execution is done with a global variable ACL=true.
After all, the node enters a selection process where it verifies:
Original block integrity.
if(ACL){}code execution results.
"Handle Exceptions"
During execution, smart contract runtime exceptions are treated as ACL failures and will display the original block with dedicated messages.
Smart contract "execution exceptions" are handled as responses and will be separated into "instances of Error" or "String-type exceptions".
The first ones will also be treated as ACL failures and will display the original block with dedicated messages exposing failure details.
On the other hand, String-type exceptions will be parsed back as responses and returned to the client following the instructions specified in the original block.
If this execution runs without concluding in any exceptions, the middleware functionality is passed, resulting in a normal API interaction. In other words, no exceptions during the ACL execution context mean that blocks and storage data are fully public. (see the Examples & Usage implementations ).
Last updated