Goal and policy-based code generation and deployment of smart contracts

Hi, my name is Grace and today we're going to be talking about co generation and deployment of smart contracts using goal and policy models. Code generation has been a very well researched problem over the last years and now people are turning into co generations for smart contracts. Our approach is there to facilitate collaboration between smart contracts. Everybody generates code for specific domains, but we want to create code that allows the user to use different smart contracts in a way that's easy to define. So you can define a model, figure out the set of actions that are required to fulfill your goal, and have the system do it for you without having to manually check. Solidity is an object oriented programming language created specifically by the Ethereum Network team for constructing and designing smart contracts on blockchain platforms. It's used to create smart contracts that implement business logic and generate a chain of transaction records in the blockchain system. Smart contracts are simply programs stored on a blockchain that run when predetermined conditions are met. They typically are used to automate the execution of agreements so that all participants can be immediately certain of the outcome without any intermediaries involvement or time loss. They can also automate a workflow triggering the next action when conditions are met. We also wanted to be able to enforce specific policies on the sequence of actions and we utilized goal models. This is an example model and in this case we have tasks which are the higher level things that need to be accomplished and and they're decomposed into further tasks or actions to an end or decomposition. We have actions which are like the leaves of these and these kinds of models correspond to a specific logic and they can be other smart contracts or can be external web services. So for example, you can see that the login has a password or they create other resources for other actions to use. And finally we have policies which are like the conditions that we need to be enforced either before preconditions or after post conditions or when an action runs. Domain Specific Language is a computer language specialized to a particular application domain. What we did here is we created the domain specific language to define such kind of models. For example, you can see the model where we've defined all nodes in the model as tasks, actions or policies. We then defined the decompositions as preconditions or post conditions for tasks or actions and finally defined contributions. So we created the hierarchy and we noticed the task and action share common functionalities. So it's grouped into a superclass called node. Again, the preconditions and post conditions are defined and then we set up the parent Node because it's a bottom up approach in tasks and actions. And then we have the action class which gives us an attribute and a method to set a resource. We also have abstract methods that allow us to set the preconditions and post conditions in the actual generated classes. The task class allows us to hold information about the children nodes. This allows us to hold information and methods that can reset again and it's deployed in the blockchain so we don't need to redeploy it again. So we have a way to reuse methods and set the children of that particular task node and also set the decomposition type and finally methods to aggregate the results. So here are some examples of code generation for some tasks. These are here for setting preconditions and post conditions and allow for connections down the line. Finally we have code for the policy and this includes information for the composition. Like policies and children and dependencies, we have ways to set the precedent. So for policies, precedent means if I have incoming contributions I have my own logic as well as which one takes precedence. And we have methods to evaluate policies on the logic and we have methods to set the specific sub policies and validate them. This is an example of a policy class which enables you to add logic instead of default value. The most important part is the populator class which is generated as a direct result of the model and this connects and creates the model. So the previous ones are there to create specific nodes, but all connections are made through the populator. We assume that the other contracts are the other generated classes and they've already been manually deployed on the blockchain. And now the populator has access to the addresses through helper methods and the helper mappings. And then we have a main method that actually performs the connections and populates the model. So we have to create instances for all the deployed contracts in order to be able to use the specific methods. So we create a sum for actions to create tasks, we create policies and then we specify the specific decompositions for the tasks and the corresponding subtalks. The utility class allows us to save and retrieve resources. So we have the contribution event handler which is an attempt at decoupling different policies. In terms of future work, we would hope to allow for greater reusability of subsets of already deployed models through our DSL support CO generation for other blockchains with different requirements and an extension of code generation to include automatic deployment with scripts utilizing the Ethereum API. Thanks for listening.