Explaining the system layer underlying the implementation of Chenilles.
The System Robustness section in our Concepts document explains why this Chenilles System Layer is necessary.
The major milestones for robustness enhancements will be as follows. Robustness work can be shared between all supported blockchains, but there is still additional work involved as the code base grows, whether by supporting more blockchains or adding more features.
Persistence is the ability for data to survive when computations are faced with adverse events such as software failure, hardware failure, power loss, remote hacking, physical intrusion, physical robbery, fires, floods, bombings, solar flares, earthquakes, tsunamis, wars, etc.
Some of these events are common, some are uncommon. Some are preventable or avoidable, some aren’t. Some are insurable, others are not insurable. The eventuality of one of them is almost certain, though which it will be isn’t predictable. Yet, with suitable software infrastructure, it is possible to survive any number of these events, and the broader the set of survivable events, the broader the Persistence.
In the first version of Chenilles, we will implement just the minimum amount of persistence required, saving data to a local database, without remote replication, and only for the simple interactions that we initially support.
In further versions of Chenilles, we will implement more elaborate persistence, with remote copies (e.g. using IPFS), and for a generalized class of interactions supporting arbitrary smart contracts.
We will implement database encryption and keep all data encrypted in the local database, based on some master password (see Password Management).
Persistence for running code, not just data. Not only will the relevant data not be lost when the adversarial events happen; the code will resume from where it has stopped right after the event is over. A short interruption is all you will experience, while the overall system “fails over” to a rebooted computer session, a spare processor, a backup data center, or whichever extra computing system will take over when the “main” one fails. Meanwhile, additional backups will automatically be started so close consecutive events won’t stop the system.
Interoperation with common existing messaging protocols and systems.
Property-based testing. Precise specification of the interaction space.
Automated inference
Integration with ssh daemon or gpg daemon or yubikey or physical key, etc.
Key parts of the system may require a formal model that allows for the development of proofs, and maybe even for the automatic extraction of correct code.
Our code will require at some point some in-house auditing, as well as an independent audit by reputable third-parties.
The Chenilles steering committee shall hire competent independent auditors before each release for each part and every part of the system, whether user-visible features or user-invisible robustness work, with enough advance to allow for integrating feedback from the audit into the system itself.
Building a healthy community is important to the enduring success of a project like Chenilles.