In order to better explain the potential offered by the Zencode Domain Specific Language (DSL) to DECODE's prototypes its important to understand the versatility of its usage. Approaches may change on a domain-specific basis and its possible to tailor and simplify usage on the specific context it applies to.
As we are on the quest to merge the description of an algorithm with its executive expression we get close to the concept of a speech act that refers to a specific context and adopts a limited taxonomy which may or may not be inscribed in a larger ontology.
At the time of writing our explanation can be based on an extended experimentation of in-vitro usage (lab tests) and a limited experimentation of in-vivo usage mostly bound to the conceptualization of use-cases in the IoT pilot and the Amsterdam's register pilot. In order to extend the coverage of Zencode to more pilots, we need to have a completed implementation of the underlying cryptographic contract, in this case the petition.
What follows is a brief visualisation of what is realised so far. In particular the first visualisation below refers to the implementation of an asymmetric cryptographic exchange in the fashion of the PGP implementation, based on an exchange of pulic/private keys and their collection into a keyring:
This simplified flow diagram shows **actual Zencode** that can be executed, higlighting variables that are normally just surrounded by single quotes. Between each code block, which is executed asynchronously as required and at different times, there is a schema which indicates the shape of data in output.
What follows is another flow diagram leading to data outputs that can be reused into the above: is the use of ECQV implicit certificates via Zencode, which leads to obtaining public/private keypairs that are compatible with asymmetric encryption.
It is very important to understand that the boxes in the flow diagrams shown contain **actual Zencode** meaning that is not just a description, but is source-code that is interpreted and executed by the Zenroom VM to accomplish the tasks described. It is then the main way to faithfully describe what the prototype does internally with the data: each of the prototypes built in DECODE can simply visualize the Zencode that is running to inform any operator of what is going on.
This solution has been realized after trying many different approaches involving visual programming and block programming, which were perhaps richer visually, but less integrated and in general consisting of a way to represent code rather than code itself. The final Zencode solution is also simplier to implement for prototyped host applications.
At the time of writing all functional prototypes in DECODE are embedding Zenroom and can therefore seamlessly implement Zencode without adding more work to implementors, but simply substituting the current Lua based Zenroom scripts to their Zencode implementation. Below a list ofsoftware prototypes also visible at https://github.com/decodeproject
- Mobile app (Zenroom embedded as a react-native javascript component, soon to be converted to native https://github.com/DECODEproject/wallet
- IoT encoder (Zenroom embedded via Go bindings) https://github.com/DECODEproject/iotencoder
All DECODE pilots benefit from this development which is successfully integrated through these components. The DECIDIM pilot still needs a working cryptographic implementation of its petition contract in order to be translated to Zencode; the IoT based pilots can all immediately benefit from the Zencode implementation of DH asymmetric encryption based on AES-GCM secure standard; the Amsterdam register pilot can immediately benefit from the Zencode implementation of ECQV implicit certificates.
Future horizons of development of Zencode include further implementations supporting interoperable and extensible crypto schemes on the same EC curve that can still work with the above implementations, as well further refinement of the parser and extension of the schema validation. From this point onwards Zencode must be informed by piloting, while it will be also refined in cooperation with legal experts to match the smart-rule statements so far identified to express consensual data processing conditions.
