How does Earth⁶⁴'s data structure provide confidentiality by design?
Permissionless Blockchains and Public Information
The development of Bitcoin in 2008-2009 initiated an explosion of new technologies based on the concept of a distributed ledger that is shared among the participants in a network. For Bitcoin and related systems this is a permissionless network, one that anyone can participate in. And the ledger is a record of all of the transactions that have taken place in the system since its inception. Crucially, this record is guaranteed to be immutable subject to the restrictions of the network protocol and its consensus mechanism, i.e. the method used to guarantee (ultimate) agreement among network participants about what transactions happened and when.
The development of Ethereum in 2014-2016 expanded on this concept to allow not only transactions that exchange value in terms of a token native to the network, but also transactions that run essentially arbitrary "smart contract" code that can involve exchanges of the native token and other tokenized forms of value. This has led to the development of decentralized applications, web applications that can interface with smart contract code running on the blockchain, and even decentralized organizations that are run by algorithms running on chain.
Despite these incredible achievements, these chains, and ones like them, have their limitations. The one of interest here is the fact that such permissionless networks, at least those that don't impost strict privacy guarantees like, for example, ZeroCash does, make the full contents of the ledger public information. This means the entire history of transactions of anyone who used the system is there, allowing anyone who can associate an identity to a pseudonymous address to know the balance and transaction history of that party. The source code of smart contracts is also there for everyone to see; this includes copycats, who want to copy your code to compete with you, and cyber criminals, who would like to steal your tokens.
Confidentiality By Default
By contrast, the Earth⁶⁴ data structure has no requirements for sharing the state of assets or the transaction history. Indeed, it is confidential by default in the following sense. The Sato-Server data structure only specifies the secure state of an asset or item of value, such as an NFT or smart contract code, and what constitutes a valid change of state. As there is no requirement to share the contents of your Sato-Server with anyone, and no restrictions placed on what sort of system is used to perform transactions, the default situation is that you only share Sato-Servers with who you want to and the transactions can be completely private.
Of course, with completely private transactions, i.e., where there is no shared record at all, there are requirements of trust among the transacting parties. But Sato-Servers can combine privacy and the benefits of permissionless blockchain networks, where the trust is supplied by the protocol rather than a party's character, by registering transactions on chain with only a hash of the contents of the Sato-Server (or some other method). Alternatively, using a ledgerless blockchain, such as TODA/IP, it is possible to keep the contents of the transactions fully private as well, to be shared only with the transacting parties.
In addition, because you are free to choose how the contents of the body of your Sato-Servers are expressed, you are free to impose on the content whatever security methods suit your needs, including encrypting the contents with the most advanced encryption algorithms available.
Permissioned Blockchains
There are other ways, however, of ensuring the appropriate level of privacy for transactions. For many organizations, the risks associated with exposing their transaction history, and other reasons including costs, efficiency, scalability and KYC laws, lead them to use their own permissioned blockchains, where they control who can participate and who can see the contents of the ledger.
Such systems, such as IBM's Hyperledger Fabric, can offer much stricter privacy guarantees than permissionless blockchains, which can be tailored to the needs of the organization. There may still be a ledger shared among a large number of participants, but there is greater flexibility in terms of concealing sensitive data. This can include complete concealment of transaction history, and representing data in the ledger by its hash and storing the data in a secure database, with well-defined identity and access management determining who among the participants in the network can access any given piece of data.
Such systems can surely be advantageous in certain contexts, but are not without their tradeoffs, including the security risks, such as concentrations of personally identifiable information, that come from centralization. But when it does make sense to use permissioned blockchains, they can also be employed by Earth⁶⁴'s data structure—Sato-Servers don't force you to choose. And this is one of the reasons why Sato-Servers offer an advantage over using such systems directly to manage your assets, because, for reasons we will now consider, they are more flexible than such systems, even in terms of confidentiality.
Flexible Confidentiality
There are many possible cases where the design of a system might require different privacy controls for different aspects of the system. For instance, there might be an aspect that requires periodic updates to a public blockchain, say for supply chain guarantees, or that requires use of a public blockchain for decentralized exchange of value. Then there might be another aspect that requires private transactions among only trusted parties, such as inter-business transactions in a consortium, or financial transactions using traditional tokenized assets but where the ledger should be compliant with regulations but not publicly accessible.
Sato-Servers contribute toward novel solutions to such design problems, because different Sato-Servers can use different systems to manage their transactions, permitting the ability to benefit from the unique characteristics of many different transaction systems, while using throughout the system a single, common data structure—the Sato-Server.
For example, it is possible to divide an Earth⁶⁴ bundle into subbranches, where each subbranch uses a different system to manage transactions. In the context of the four scenarios described above, you could have one subbranch of your bundle of Sato-Servers use a layer 2 solution over Ethereum for value exchanges, another subbranch use Cardano for supply chain reports, another use Hyperledger for inter-business transactions, and another use TODA/IP for private, regulation-compliant transations. The possibilities are endless.
Once again, this is possible because Sato-Servers only guarantee validity of state changes but not how they are made, providing unprecedented flexibility in the management of the state of digital items of value.
This means that any given Sato-Server is not forced to use a single system over its lifetime. It is possible to have a Sato-Server that starts its life being managed centrally using AWS' quantum ledger database (QLDB), and then later on be managed on Cardano, and then eventually TODA/IP. And a wide range of other possibilities also exist.
This level of flexibility when choosing transaction systems gives you the ultimate flexibility when designing for specific forms of confidentiality, which might change over the lifetime of your organization, might change over the lifetime of a particular branch of your Earth⁶⁴ bundle, and might change over the lifetime of a particular asset.
Not all of these capabilities can be used out-of-the-box right now, but they are inherent in the design and will be available in a subsequent phase of the development of Earth⁶⁴. It is the very fact that these capabilities are inherent in the Sato-Server structure, however, that shows the power of Earth⁶⁴'s confidentiality by design.