However, it can be assumed that these examples have probably developed from one another and from the lines of development listed. Therefore, some advocates see smart contracts as a necessary further development of independent efforts to achieve improved opportunities for transactions in the various industries using digital technologies. For this reason, various formal languages have already been developed which can be used to map contractual clauses into software. These efforts are also supported by the Institute of Electrical and Electronics Engineers based in New York, which has already held various workshops on the subject of electric contracting.
The replicated title and contract execution for Smart Contracts
The infrastructure required for Smart Contracts can be implemented through a replicated asset register and the subsequent execution of the contract through cryptographic hash chains, as well as fault-tolerant replication.
In a peer-to-peer network, any node can act both as a register and as a trustee. The change of ownership is performed in these nodes, and the rules that can be checked for the respective transaction are automatically mapped. The fact that all transactions must be audited by all other nodes is an additional safeguard for the parties involved in a transaction. The description language for the contracts in 2002 was the Askemos procedure Scheme, a programming language developed in 1975, later SQU was used instead.
In the Askemos process, the conventional electronic signature was replaced by a dynamic and multilaterally coordinated signature. The great advantage of this procedure is that the documents are no longer located in a place where they can be destroyed or manipulated, but are stored in distributed form. This not only provides better protection against tampering, but also makes the system less susceptible to technical failure.
If two parties want to conclude Smart Contracts according to the Askemos procedure, they must first of all agree on four providers, which are legally and technically independent of each other. Another prerequisite is that all participants use an asceemos network such as fiXml. Before the contracts are concluded, one party must authenticate itself with the providers, which in the best case happens with different procedures. One party then saves the contract text with all providers. In addition to the actual document, further information, such as the sender of the document, is stored. A checksum is automatically generated from this data, which is also saved together with the document.
The other party then has the right to access the data. If the second party accepts the offer, it must in turn submit a document with the promise to the providers, referring to the offer, so that offer and acceptance can be automatically linked. The conclusion of this contract can thus also be proven in court proceedings. The proof can be provided by an Internet-capable computer as well as by an Askemos access. Once the request for evidence has been received by the court, all that remains to be communicated to the court is the identifier of acceptance so that the court can verify the authenticity of the documents.
However, Askemos is merely a contract description language describing a concept that allows independent registers to be checked with arbitrary values. However, the registers are not linked to a specific value, such as a monetary resource. The different crypto currencies contain special cases of such registers in which the respective crypto currency is contained. Numerous crypto currencies also contain various mechanisms through which general assets as well as smart contracts can be managed. For example, the crypto currency Namecoin contains a replicated domain name registry. Other currencies such as Ethereum or Ripple contain replicated securities for different asset classes.