{"id":1515,"date":"2021-02-15T13:55:13","date_gmt":"2021-02-15T12:55:13","guid":{"rendered":"http:\/\/szzccmv.cluster031.hosting.ovh.net\/?p=1515"},"modified":"2021-10-26T18:20:15","modified_gmt":"2021-10-26T16:20:15","slug":"smart-contracts-and-regulatory-compliance","status":"publish","type":"post","link":"https:\/\/n.world\/en\/smart-contracts-and-regulatory-compliance\/","title":{"rendered":"Smart Contracts and Regulatory Compliance"},"content":{"rendered":"
Smart contracts are computer protocols that facilitate, verify, or enforce the negotiation or performance of a contract, or that make the contractual clause unnecessary. Even though the term \u201csmart\u201d does not justify for all the contract that are out there, we are still far from having truly contracts that are smart<\/strong>.<\/span><\/p>\n Quite the contrary, at this point in time they are quite \u201cdumb\u201d and full of vulnerabilities that can make people lose tons of millions of dollars. Within the context of the Distributed Ledger Technology<\/strong> (DLT from now on), such protocol or application also uses the ledger to store information and to achieve consensus among peers.<\/span><\/p>\n This means that one can implement a smart contract without a distributed ledger since from the functional point of view, the protocol is not more capable depending on how the information is stored, or how the consensus is reached. The key is, again, trust<\/strong>. An application is as trustworthy as it is its infrastructure and provider. Some companies decide to use Gmail or Outlook 365 because they trust Google and Microsoft to store their private or sensitive information. The email service provider would be the equivalent of the central authority.<\/span><\/p>\n DLT allows the implementation of a smart contract<\/strong> between parts that neither do not trust each other nor the broker, in the context where a central authority used to be a fundamental requirement, is no longer required as long as all the information stored within the ledger is public. Bitcoin can be defined as a smart contract implemented using the Blockchain as a means of obtaining storage and consensus.<\/span><\/p>\n All the technology described so far is only the storage and peer consensus part. It all lacks any business logic to be useful for any purpose. Any modern DLT exposes an API to create a smart contract, where the inner workings of the storage and the consensus are hidden to the developer and the user. Writing a smart contract feels like writing a program<\/strong>.<\/span><\/p>\n Some API may be more feature-extensive than others<\/strong>. Some may allow a node to subscribe to events and react to them, changing the state of the contract accordingly. Or they may provide some sort of authentication and user permissions system. In any case, the application layer is way beyond the details of data persistence and the consensus protocol.<\/p>\n It is key to emphasize that applications are as complex as they need to be, and a DLT may not reduce that complexity at all if it comes from the functional requirements. The main contribution of the DLT is that some algorithms that had to be run on a single computer, and where the data was stored, can now be distributed over a network of computer<\/strong> with a limited amount of trust between each one of them. <\/span><\/p>\n One should understand that this reduced amount of trust in peers does not mean that the application is any less robust against real-life attacks, like stealing keys or credentials. What it means is that users can now use a trustless system<\/strong> without a central party telling them what or who to trust.<\/span><\/p>\n There are two major platforms of DLT-based smart contract platforms contemporary to this document: Hyperledger and Ethereum<\/strong>. The underlying design of both platforms is similar, being Ethereum the first to blueprint such a structure. The main idea is that the ledger must store the status of the contract and the program itself.<\/span><\/p>\n This is kind of a revolutionary idea. The database stores the state of the system and the code necessary to mutate it. The main difficulty of this approach comes from one essential characteristic of DLT: any node must be able to verify all the states of the contract<\/strong>. This means that all the nodes should be able to run the program too and obtain exactly the same results as any other node that participates in the network. <\/span><\/p>\n This requires the implementation of a small virtual machine<\/strong> that is fully deterministic on all its results, avoiding some important hardware optimizations. This means that the DLT is a distributed computer, a particularly slow one at the moment. On the other hand, this allows full generality of a smart contract: a modern DLT may run any kind of program without affecting the consensus in any way.<\/span><\/p>\n The primary goal of DLT with built-in Smart Contracts is to create self-enforcing agreements<\/strong> that independently control and automate the exchange of value according to predetermined rules based on predefined inputs recorded into a smart contract. In simpler words, the end goal is to create a contract that cannot be changed, reversed or controlled by any party. Smart Contracts are software applications that are shared and run on all the nodes (computers) across the DLT network. <\/span><\/p>\n Smart Contract platforms like Ethereum<\/strong> were designed to lower the trust needed in third parties and, enable users that did not know each other to enter into a software-enforced agreements that are censorship resistant, meaning that no party can alter the code or prevent its enforcement. Below, an illustrative image of the life cycle of a smart contract.<\/span><\/p>\nCurrent platforms for DLT-based smart contracts<\/b><\/h3>\n