BackgroundOverview of Smart Contracts as described by Nick Szabo (
http://szabo.best.vwh.net/smart_contracts_2.html).
The four basic objectives of contract design could help us frame an approach to secure the generator pool:
- The first of these is observability, the ability of the principals to observe each others' performance of the contract, or to prove their performance to other principals.
- A second objective verifiability, the ability of a principal to prove to an arbitrator that a contract has been performed or breached, or the ability of the arbitrator to find this out by other means.
- A third objective of contract design is privity, the principle that knowledge and control over the contents and performance of a contract should be distributed among parties only as much as is necessary for the performance of that contract.
- A fourth objective is enforceability, and at the same time minimizing the need for enforcement. Improved verifiability often also helps meet this fourth objective. Reputation, built-in incentives, "self-enforcing" protocols, and verifiability can all play a strong part in meeting the fourth objective.
- The threat of physical force is an obvious way to embed a contract in the world -- have a judicial system decide what physical steps are to be taken out by an enforcement agency (including arrest, confiscation of property, etc.) in response to a breach of contract. This is called a reactive form of security.
- A proactive form of security is a physical mechanism that makes breach expensive, such as a combination lock that makes access to a room containing trade secrets expensive without explicit authorization.
- A canonical real-life example, which we might consider to be the primitive ancestor of smart contracts, is the humble vending machine. Within a limited amount of potential loss (the amount in the till should be less than the cost of breaching the mechanism), the machine takes in coins, and via a simple mechanism, which makes a beginner's level problem in design with finite automata, dispense change and product fairly.
Generator Pool Security Problem Overview - A small number of cold storage generator pool wallets exist that have a large amount of SLR. They need to remain secure for many years (40+) and will be the supply of SLR for generator facility grants.
- A small number of granting wallets were created to receive SLR from the generator pool wallets.
- SLR needs be released from the generator pool wallet to the granting wallet in a small fixed increment (i.e. 100K SLR) to reduce the "at risk" SLR footprint.
In alignment with the objectives of observability, verifiability, privity and enforceability, below is an approach (open for discussion) inspired by double escrow smart contracts to secure the SLR generator pool from a needs and constraints basis.
Proactive Security Process - When the amount of the granting wallet drops below a trigger (let's say 10K SLR), 100K SLR from the generator pool wallet is automatically staged as escrow in a smart contract.
- Another 100K SLR must be put up as collateral in the smart contract from a wallet that is not from the generator pool.
- Once the transfer of 100K SLR has been confirmed on the blockchain from the generator pool wallet to the granting wallet, then the 100K SLR of collateral is released back to the wallet it came from.
- If the 100K SLR does not get confirmed on the blockchain by some defined criteria, the collateral is forfeited back to the generator pool wallet, keeping it whole again.
CommentaryWe can add elements of multi signatures to wallets for added security, but there must be 100% "skin in the game" as collateral to guarantee that SLR is released from the generator pool according to protocol with the insurance that it will always kept whole during the process. The 100% collateral posting in a smart contract with confirmation from the blockchain removes human intervention as the main deciding factor in the transfer process. The vending machine analogy inspired the proposition that an equal amount of collateral (i.e. 100K SLR) must be posted in a smart contract to release coins from the generator pool wallet to the granting wallet. This proactive form of security makes breach expensive and is much easier to implement than reactive security.
FeedbackThe SolarCoin Foundation would like to consider community feedback on innovative ways of securing the generator pool wallets to explore possibilities from different perspectives. (i.e. POS wallets could provide the collateral to secure and release SLR from the generator to the granting wallets). We look forward to community input on this discussion.