Gates and Smart Accounts.
Gates are a new concept to compose complex trustless flows by upgrading accounts to smart accounts that react to events.
They will allow to extend the capabilities of the Lexon language, similar to a standard library, but with the benefit of adding a new paradigm to trustless transactions. Gates are described in detail in the 2023 Lexon Whitepaper.
A gate is a voluntary, per-account restriction on the use of an account’s tokens. It can be used to express obligations, which smart contracts generally cannot. Technically, gates are separate, re-usable callback function collections, tied-in through special event hooks in basic token functions, like transfers. Once put in place, they cannot be bypassed.
Gates and Smart Accounts are an extension of the Lexon Token.
Whitepaper >The trigger of a gate can be an out-of-band fact, communicated by an oracle; a special event like a promise or a commitment being made or changed (see whitepaper); or an incoming transfer. The gate can be programmed to intervene in any of these cases, to, e.g., stop the transaction or to make a token transfer to a third account immediately following it.
The gate restrictions allow others to trust that a smart account’s owner must honor the obligation expressed in its rules. Like with the general blockchain paradigm, the power of gates lies in the unbreakable promise they allow to be made. Some uses of gates are trustless, e.g., in connection with pending commitments or reversible transfers. Other useful setups start out trustfully, relying on out-of-band incentives that make sure that a smart account – and thus its gate – is actually used, and not sidestepped to escape the gate’s restrictions. Such scenarios fit business settings where there exists some trust – if in the judicial system as backstop; and for friendly interactions that use tokens as a unit of account only, where there is no gain in open, traceable sabotage of the bookkeeping.
A gate is like a smart contract built into an account, instead of existing ‘between’ accounts. It is more efficient than the typical smart contract flow, where a transfer often takes three steps (pay in, trigger, pay out), and tokens get locked in at the smart contract’s internal escrow between step 1 and 2, i.e., before anything really happens:
Because a gate shifts the logic into the account, one step is eliminated. There is no preparatory step 1 for the rules to kick in, and the tokens are not locked-in while the transaction is pending.
Gates tie into the mechanisms of approval, commitment, reversibility, promises, and deeds (see whitepaper) and can extend them. They basically provide functions that are called at the time of specific events, for example, when a transfer comes in, a promise is forgiven, or a transfer reversed. They can consist of a single one-line function or be a complex, stateful object. Gates have temporary access to incoming tokens.
A gate can provide its rules to an unlimited number of accounts. It is set or prepared by an account owner, who elects the specific gate to become the unshakeable extension to the token functionality of the account. The owner can also assign a keeper of the gate. It is then activated by the keeper, confirming the settings, and paying the fee if there is any. An account can only be gated with consent of both account owner and gate keeper, if there is one.
Whenever a transfer is initiated from the gated account, the gate smart contract is called first with the information from whom to whom and on what amount the transfer is to be. The gate contract can then veto the transaction. When a gated account receives funds, the gate is called and can cancel the transaction or draw part or all of the received amount from the gated account. An internal locking mechanism prevents re-entrance circularity.
Gates can be programmed to be permanent, or to close according to specified rules. The keeper, or the gate itself, can close a gate and thus restore a smart account to its default, non-smart state. The keeper can also update parameters of the gate contract, if there are any. What parameters control a gate depends on its design. The owner of a smart account will have had insight into it before accepting the gate. Both the owner of a smart account and its gate keeper can retrieve information about the gate’s status, which can be of any complexity.
Gates can be re-used, which allows for standard implementations to emerge. Gates increase the cost of a transfer, depending on the intricacy of their event handling.
Decentralization of Logic
Conceptually, gates are a more decentralized administration of logic than smart contracts, with the expected advantages. The relationship topology of a complex smart contract typically has a star shape, revealing its centralizing effect. This is what graphical blockchain browsers often show.
In contrast, the gate mechanism, being per-account, replaces this pattern with a web of direct connections, introducing intricate peer-to-peer interaction between accounts.
This is more robust and better suited for growth than a star shape, as it allows for incremental progress in the development of relationships; rather than requiring the limiting, holistic and even dictatorial approach that characterizes the design of bulky smart contracts.
Each account can be fitted with custom logic independently and the cascade of algorithms that interact to implement complex business logic can be built up in successive steps. Notably, the individual building blocks are malleable – correctible and improvable – with authority to change accruing to exactly those parties who would stand to lose from a change. Even the most complex governance mechanisms could but approximate this modularity for a central smart contract.
Dynamic Stacking of Logic
A main advantage of gates is the more dynamic flow: tokens need not be moved out first, and the application of rules across participating accounts can be stacked, for high complexity. The cascading transaction cost can be shared.
The interaction between the account-specific rules is ad-hoc, for any specific transaction.
The two gates that may be involved are independent and oblivious of each other. In sum though, they form a loosely coupled emergent system. Such dynamic interaction was an original hope for blockchain smart contracts. It is being held back by the lack of API definitions, now addressed by the community-driven EIP process that does not aspire to be fast. Gates are magnitudes simpler, individual decisions. They work without intra-contract standards because their tie-in is not between accounts. Gates may affect each other but need not talk to each other.
Proofing Programmable Money
Gates demonstrate a mechanism to securely track hierarchic channels of supply chain cash flow to speed up disbursement and reduce risks of trade financing, or to implement complex bookkeeping, e.g., for staggered media royalties. An ultimate employer does not have to lock-in the entire budget of a contract into a smart contract but merely commit to be using a specific account to trigger a pre-agreed, unstoppable distribution mechanism. After that first trigger, the transfer mechanism can be trustless. If the ultimate employer desires that subcontractors – who do the actual work – get paid, incentives are aligned.
Gates thus demonstrate the possibility of programmable money, as proposed at the Cleveland Federal Reserve in 2018: for a specific budget to reliably and continuously be subject to specific rules, a system architecture must provide for the programmability of individual accounts. This enables the metaphor of the funds themselves being programmable. Neither traditional blockchain smart contracts nor traditional automated banking mechanisms are sufficiently subtle for this purpose. A shortfall that inflicts significant economic cost, most commonly in the form of late or denied payment that punishes the productive party to a contract. To address this well-researched power abuse, some of the relevant logic must be anchored in the layer of the code that implements the token, rather than at the higher layer of the contract logic.