In a world where personal human interactions require the exchange of value, two issues emerge.
The first one is that more people are involved with the use of smart contracts and for this reason they must be understandable or even produced by non-technical (e.g., business) people. The need to have understandable smart contracts creates a market where a smart contract can be usefully deployed to support a small number of parties. As an example, a contract produced by a lawyer is used by the involved parties and it does not require mass adoption to be successful.
This goal, e.g., providing smart contracts for a large number of different situations, requires scalability in terms of number of different smart contracts that can be deployed in parallel.
In many of these situations, pure performance is a lesser issue as the volume of transactions might be lower and slower. As an example, the management of real-world risks, usually called insurance, shares these properties. In this situation, contracts settle on a time frame that is much slower than applications in the DeFi space such as DEX.
Our approach is based on Expressive Smart Contracts (ESC) already described in a previous post of this blog. In a nutshell, an ESC is implemented using a language based on BPMN and DMN, languages that have been standardized by the OMG and provide a low-code approach to the description and execution of a business agreement. In our previous posts, we assumed that the parties involved in the contract reach a mutual agreement and, should an exception arise during the execution, that they have recourse to the rule of law.
In this post, we relax these assumptions and start from the same example of a chess game discussed in a previous post, assuming that the parties cannot trust each other and have no recourse to the rule of law. For this reason, they need an alternative way to settle a dispute, should a disagreement arise.
In this example, the time scale of the interactions is measured by the human ability to conceive a move in a chess game and the volume of transactions is very small since it accounts for the moves of the two players.
Another issue revolves around the management of malicious behaviors. If one of the two players, called A and B from now on, violates the rules of the game, the other player should win. If they have pledged an amount of money that will be given to the winner, winning means that the payment is executed even if the other party disappears. From these simple remarks, the contract requires the inclusion of the full set of rules of the chess game in order to determine its outcome. This requires the embedding of a complete chess simulator in the contracts available to the parties.
A note on the ecosystem
In our model of a game, the two players are supported by three external entities: Historians, Messengers and Judges. The overall process is organized so that a certified history of the game is produced by Historians with all details allowing a third party (e.g. a Judge) to replay it. Here, Messengers are in charge of connecting players with the other services, Historians receive the information from the Messengers, certify and return to the players through the Messengers the history of the game while Judges are invoked when the parties are not able to reach an agreement on the end game.
The ecosystem supporting this model of ESC benefits from the existing infrastructure developed around Bitcoin. For instance, the availability of a Decentralized Identity system (DID) such as ION where the characteristics of the various smart contracts and the capabilities of the actors are listed supports the development of a marketplace of services and dealmaking. For instance, we expect that services providing ratings to the actors will emerge and guide the choice of the players.
All of these services will require micropayments since all actors are for profit. While not limited to this model, we assume that a Lightning Network payment system will be able to provide the granularity of payments that support the economic model of the ecosystem. A possible economic structure of this ecosystem will be the topic of a later post.
For sake of simplicity, we will also assume that the identifiers of all parties can be interchangeably used as Public Keys, associated to a Digital Signature, and identifiers in a censorship resistant Messenger such as Nostr so that information can be reliably exchanged.
Secure hardware technology for Historians and Judges
Services provided by Historians and Judges are supported by a distributed infrastructure that relies on a number of secure hardware devices (SHD) in order to provide a remote attestation of the fairness of their activity to the players. All of these devices share a few properties:
provenance from a known and accepted silicon provider that certifies their characteristics; usually this is obtained by embedding a device-specific signature of the silicon provider in the SHD;
a unique identity created by a sequence of bits internally generated by a true random number generator. This identity is used to support all protocols based on public and Private keys;
a way to report the status of the device memory after uploading the code required to execute the task. This property offers strong guarantee that the code in execution is the one that is supposed to be in use;
a number of technologies preventing device tampering, leading to a full reset of the device in case that situation should happen.
The SHD are interfaced to the external world through conventional IT systems, providing memory storage, connectivity and protection against (D)DOS attacks. The focus of the following posts will target the definition of the protocols that guarantee the definition of a result consistent with the algorithm and with minimum resource requirements from the infrastructure.
This organization minimizes the attack surface of the protocol and the complexity of its analysis.