.png)
The reality of many business transactions is that not all participants may be known at the start of the workflow. And it's not just about adding new ones; existing participants may elect to terminate engagement. As obvious and prevalent as this may sound, conventional blockchains and distributed ledger technology (DLT) have several interesting challenges in accommodating this need:
Versioning or otherwise modifying the parameters of the smart contract is non-trivial. In the worst case, a new contract must be created which changes the active contract address and essentially changes the "unique key" to the contract. Sophisticated front-end dispatch/proxy contracts must be set up at the very start to make this activity even remotely practical.
When the complete and unchanging set of participants is established up front, the contract may "lock" in the engagement of the participant for the full lifetime of the workflow, which can derail an workflow if participant ceases to sign or otherwise perform actions on the contract.
Susynct avoids this problem by careful segregating and versioning three things:
The record specification for the underlying data including entitlements (create, modify, audit-only, etc.) for each participant for each defined section of data within the overall record
The actual underlying data. Note that each section of data in a record is versioned independently of other sections
The smart contract code itself. Smart contracts are just data, like "regular" data, and are versioned and historically accessible and executable without recompiling or reconfiguring resouces
Thanks to discrete versioning of entitlements, contracts, and data, it is possible for entity ABC to participate in sharing and modifying section X from time 1 to time 4, be excluded from the group from time 4 to time 8, then reengage at time 8. Because cryptoassurance is applied to individual versions without the need to incorporate hashes or other material from previous versions, participant ABC can "step right back into the flow." It is of course possible for the rest of the group to decide to share the material from time 4 to time 8 with participant ABC, and a special instruction will cause this data to be pushed to ABC where it will fill in the time gap without collisions. Note that Susynct treats data privacy and distribution from the principle of "water under the bridge": once data is determined to be eligible to be shared and lands in the database infrastructure of a participant, Susynct considers it "released." There is nothing to stop a participant from creating triggers, making backups, etc. to create a *secondary* copy of the data outside of the control of the Susynct daemon, so Susynct has no -- and needs no -- mechanism for "remote coordinated removal" of material.
Another key design feature of Susynct is that contracts "overlay" underlying rich shaped sections of data; the underlying data becomes the state for the contract. This means not only can one contract version be applied to many different instances of state, it moves data entitlements from the complex world of contracts and objects to the code-free data layer. In other words, regardless of the complexity of the smart contract and conditional logic, at the end of the contract execution one or more sections may be marked for update and then the same entitlements checks and group cryptoassurance kicks in, just as if a regular simple instruction to "set the new section version to this" was issued. And because all contracts are versioned and stored, all historical events can be replayed from time zero and the correct point-in-time versions of underlying data and record specifications and contracts can be brought together.