Abstract
With centrally maintained data stores acting as the main trusted brokers of data, environmental information is being skewed and sold and reality is being virtually
misrepresented. Combined with the advent of AI, online trust has never been lower and
digital deceit is running rampant. While current blockchain based solutions do offer some modalities for alleviation, their complexity and separation from the traditional web space has greatly limited mainstream adoption. In order to offer a flexible and decentralized data trust solution that is compatible with current mainstream technology it would prove much more efficient to focus on creating efficient decentralized memory systems rather
than entire applications. This paper focuses on a flexible and efficient memory centric
approach to blockchain based network states and their possible utility for establishing
automatic trust and data freedom across centralized and decentralized digital systems. Through this approach applications are split into on-chain data structures and off-chain algorithms providing the benefits of decentralized data while maintaining the freedoms of traditional digital infrastructure. Additionally, as code execution is handled off-chain, the on-chain data structures may be built without code, minimizing barriers of entry and reducing risk and possible overhead for network participation.
1. Intro
Distributed systems can benefit substantially from the wealth of untapped reference material found in naturally occurring systems throughout the universe. These systems have been continuously optimizing and evolving since the beginning of time, ranging from the cells that make up the largest known organism on Earth to humanity itself. Utilizing natural systems as a model for distributed consensus we may observe a unique solution that provides a new basis for non-central, securely verified web-based communication.
2. Background
By observing the largest known organism on Earth (a honey fungus) and using mycelium as a frame of reference, we can identify a more efficient solution to decentralized networking. Mycelial nets don't have a localized "brain," so all the cells (hyphae) that make up the system are constantly processing information related to their surrounding environment. As the environment changes, the system can adapt and reallocate resources to optimize for the environment's next state. Full participation in environmental data collection across the system allows the best decision to be made for the network. This is done through enabling the collection and consideration of all relevant information, thus creating opportunities for environmental adaptation and selection of the most ideal next step for the network.
Looking at the internet and current digital networks, systems are currently extremely vulnerable to misrepresented environmental information as the data centers or ‘nutrients’ that define truth and value are maintained and verified through centrally verified data stores. For all relevant perspectives of a system to be considered accurately for proper environmental adaptation, the first step is defining a decentralized basis for informational accountability so that each perspective in the network is accurately represented in a trustworthy manner.
3. Accountability vs Predictability
Issue - Digital Data Trust and Security
Smart contracts - decentralized Automation (predictability) (what's going to happen)
Cyphae - decentralized Evidence (what happened)
When defining trust there are two major options. Trust may be defined by finding ways to
accurately verify what has already happened in the past or by creating systems for predicting what will happen in the future. In most cases, this translates to accountability of system entities and interactions or through the predictable execution of pre-determined processes across a network. The ladder of these two approaches is the core approach driving the current web3 space that is plagued with mistrust. This approach is data-heavy, rigid, and its immutable logic directly opposes the natural iterative nature of technology, fostering homogeneity over unique innovation. Instead of defining a system as decentralized through decentralizing the code execution, Cyphae is designed to create a decentralized map of entities and interactions, verifying each entity's unique history in the system through action-based evidence and accountability.
With the ability to quantify systems through a series of entities and connections, Cyphae
provides a simple framework for creating verifiable data maps of the digital space that allows users to verify everyone's unique digital history. This also creates a simple framework for centralized organizations and applications to easily verify their operations through no code on-chain transactions without the overhead and risk factor of typical smart contract, or blockchain-based operations. Through this system, Cyphae is focused on creating an accessible, flexible and easy-to-adopt solution for decentralized security, trust, and accountability that fits into the traditional web framework.
4. Network state
4.1 blocks, transactions, and network state (high-level overview)
Cyphae is a layer one blockchain maintained by a distributed peer-to-peer network of nodes through a combination of Cyphae’s unique Proof of Presence and a delegated Proof of Stake BFT consensus mechanism. This network of nodes works together to process transactions in groups called blocks. Once blocks are processed they are maintained by the network of nodes to be used as a verifiable history of state changes. Each time the network of nodes creates and processes a new block of transactions a new network state is created to reflect the changes outlined by each transaction in the block. Cyphae’s network state is composed of an array of account objects with recorded incoming and outgoing connections that may be used to create unique on-chain data
structures and interaction instances.
4.2 Entities and interactions
In order to provide a fully encompassing adaptive framework for decentralized virtual
accountability Cyphae’s network state consists of a record of entities and interaction instances. This openly verifiable record of entities and interactions is central to the network's function as a hub for verified data as it is highly accessible, flexible, and simple to integrate. Rather than verifying entire code/logic execution processes on chain this action based evidence system allows only resulting actions to be verified through a third party verifiable, open access data map, updated through network transactions.
4.3 Verified Interactions
Interactions are verified through splitting each interaction into a verified of -chain data exchange and an on-chain intent to interact.
Cyphae utilizes 2 types of interactions for decentralized verification. These types include open and closed interactions. With open interactions the content of the interaction is publicly verifiable through an on-chain record of who was involved and what the interaction consisted of. Closed interactions exist as public record on-chain to verify the interaction has taken place, however, the contents of that interaction must be disclosed by one of the involved parties. In order for an interaction to be established and verified the most important part is first defining the involved parties.
Verification of the involved parties is done through a directional outgoing on-chain connection created with a Cyphae mainnet transaction, by the party who started the interaction. Once this connection or “intent to interact” has been published to Cyphae’s mainnet the interaction's existence then becomes public knowledge and verifiable.
The next step is attaching data to the on-chain intent to interact. Since this intent to interact is public on Cyphae’s main net the presence of the interaction can be easily requested and verified through referencing the on-chain connection. The specific contents of the interaction can then be verified as well through requesting the signed data exchanges tied to the on-chain intent to interact. Through this system each user is able to own and control their own data through being responsible for storing the history and contents of their own interactions.
As users continue to exchange data upon an on-chain connection the contents of the interaction grows as a result. In the case of an open interaction the data exchanged on the connection may be verified as most current, through an on-chain connection hash that verifies the current state of data exchange for that interaction instance.
Each verifiable data transmission consists of a message, data token, and signature. The data token and signature are responsible for verifying the message and linking the data to Cyphae’s mainnet. The data token contains the sender Cyphae ID, receiver Cyphae ID, nonce, outgoing connection index, incoming connection index, a hash of the message, and the most recent Cyphae mainnet state hash.
API’s and more detailed instructions for creating and verifying interactions will be found in API and data exchange docs.
4.4 Simplified state overview
4.4.1 Simplified State Structure
The Cyphae network state ledger contains a current record of accounts and connections. Blocks record a history of the changes made to this ledger. This ledger may be separated into 2 layers of connections for ease of understanding.The user connection layer & The consensus connection layer.
4.4.2 State Connection types
Account-Account connections (user layer) 1-way, 2-way
Account-Account connections are 1-way input/output ledger connections formed
between accounts and stored on the network's ledger. 2-way connections may be
created through both accounts creating 2 opposing 1-way connections.
Account-Node connections (integrate user layer with node/consensus layer) 1-way
Account-node connections are singular 1-way ledger connections of a single account pointing to a single node store on the network's ledger (one per account). The account in this connection is an account being represented in consensus by the node.
Node-Node connections (node consensus networking layer) 2-way
Node-Node connections are traditional web based 2-way connections used for relaying
information amongst the node computers in the network.
4.4.3 User connection layer
The user connection layer is composed entirely of incoming and outgoing account-account connections. These are the connections utilized for general network use. These connections are all unidirectional (incoming/outgoing), however, two opposing 1 way connections may be used to simulate a 2 way connection.
4.4.4 Consensus connection layer
The consensus connection layer contains the connections used in distributed consensus. Non-node accounts use 1-way account-node connections to be indirectly involved in network consensus through showing their support for a selected node. Network nodes hold a basic record of traditional web based node-node TCP/IP connections to give each node a general idea of the computers in the network. These are the connections used for nodes to communicate amongst each other and reach consensus on each new block.
4.5 simplified account structure model
The following is a simplified overview of the account structure for each entity on Cyphae. Each connection in the accounts outgoing record contains the outbound account index, and a connection state hash(40 bytes). When creating a new entity the creator account may choose to make the new account a child, creating an automatic outgoing connection from the child account to the parent account and permanently activating the child account’s child account flag. The host node ID represents the node account that the non-node account is supporting. If an account wishes to be evaluated as a potential node account they may select themselves as host node.
Simplified account structure:
Field
Size
Description Data Type Comments
4 index uint32 Account number
32 Public ID char[32] Account public id signature
8 balance float Account balance
32 State hash char[32] 32 byte field that may be altered at the will of the
account owner
32 Host Node ID char[32] ID of account host node
2 Child flag Flag used to determine if account was cosigned on
creation
2 Tradeable flag Flag activated on account creation, used to determine
if this accounts outgoing connections may be freely
traded as an asset
? outgoing Public ID[] Public id and state of outgoing connections. (40 bytes)
? incoming Public ID[] Public id of all incoming connections. (8 bytes)
5. Creating on-chain data structures
5.1 data structures and algorithms in applications
Data structures and algorithms are fundamental concepts in computer science. They refer to the organization and manipulation of data in a way that is both efficient and effective. Data structures provide a method of system memory and the algorithms provide instructions for how that memory may be updated. In the case of most applications, this means that trust may only be facilitated by those who control the system data structures or ‘memory’. In order to facilitate trust across a system without a trusted third party a decentralized framework may be utilized to simply connect and verify each system's data structures.
5.2 mutual trust through public verified data structures
Through creating public data structures that may be shared and verified across ecosystems, users are able to create a mutually verifiable basis of trust without the need for verifying expensive on-chain logic execution. These shared data structures provide the framework for creating a trustworthy distributed memory system for verifying data integrity and accountability across ecosystems. Looking at humanity as an example we see that trust is most difficult to facilitate between entities that hold different memory systems.
Creating a decentralized shared memory system allows individual systems to operate their
logic systems off chain while staying connected through a common trusted memory. This
framework frees the flow of trusted data across the digital space as trusted data integrity, flow and storage is no longer restricted to the traditional centralized channels. This not only creates new venues for how data may be stored reliably but also creates multiple opportunities for system collaboration and interoperability as systems may operate under a common trusted memory system while maintaining complete unrestricted freedom of operations.
5.3 data structure examples
Cyphae’s account and connection based network state provides the perfect foundation for giving users the ability and flexibility to create decentralized data structures with ease. Instead of needing to learn a new development ecosystem, or even needing to code at all, users can build nearly any data structure on Cyphae through account and connection based transactions.
5.4 how to create data structures
On-chain data structures are created through the transmission of transactions. These transactions generally contain requests to create and edit on-chain accounts or to create or edit a connection instance between accounts. Once a new translation has been created, they are then sent to an active node before being relayed across the network and confirmed. Upon transaction confirmation the new data structure will be added to the network state allowing it to be publicly accessed and verified by anyone. If the on-chain data structure diverges from the off-chain application users can verify that the application is operating dishonestly.
5.5 Tradable Assets
The outgoing connections of a Cyphae account may also be utilized to represent unique digital assets that may be easily exchanged between accounts through simple on-chain connection transfer transactions. These outgoing connections may only be traded by the account receiving the outgoing connection if the account sending the connection has its ‘tradable’ flag activated. If the account that created the outgoing connection does not have its ‘tradeable’ flag activated the outgoing connection acts as an immutable asset permanently owned by the account receiving the outgoing connection.
5.6 decentralized neural networks
Using Cyphae’s modifiable state record of accounts and interactions Cyphae may be utilized to build decentralized neural networks that are held on-chain. This is done through treating accounts as neural nodes and utilizing account connections to store and display the relationship between each neural node (synaptic weight/tolerances, data exchanges). Through this approach neural networks may be trained off chain and updated on-chain to provide an open verifiable record of memory based systems. This allows Cyphae to provide a flexible and efficient foundation for decentralized neural network interoperability and trust without the need for executing resource intensive training models on chain.
Based on the current hardware limitations, for the meantime it will most often prove more
efficient to verify artificial intelligence through interaction history - the same way nature verifies biological intelligence. Cyphae’s entity and interaction based framework may be utilized to verify the prompt and response history of AI based systems. This allows Cyphae to provide a verifiable reputation/possible bias profile for biological and artificial intelligence online.
6. Transactions
6.1 sending/relaying transactions (gossip)
Transactions are distributed across Cyphae’s mainnet of nodes through a basic gossip protocol. This ensures all active nodes have a similar perspective on the new transactions being processed by the network so they have the tools necessary to create new blocks. Each transaction requires a valid signature from the requesting account as well as a valid balance to execute the transaction and pay the transaction network fees. Network fees are determined collectively by each node based on personally set minimum fee thresholds.
6.2 node transaction pools
As transactions are relayed throughout the network, nodes store new transactions they were not previously aware of in a locally contained transaction pool. Once the number of transactions contained in the nodes transaction pool reaches a certain threshold, defined by the last block, the node is then able to build a potential next block for the network and participate in consensus.
6.3 Block size increase/decrease function
Block size on Cyphae is designed to grow and shrink to account for variable network traffic demands. The next block size is determined depending on the excess number of transactions contained in each node's transaction pool after a node creates a new potential block for consensus. Depending on the excess percentage in each node's transaction pool, each node then adds a flag to increase the next block by 10% or decrease the next block by 10%. This flag is what determines the size of the next block. Each node has a locally defined maximum size in which they stop approving blocks to ensure block sizes do not get out of hand.
Flag = 0, If excess = 0 :
Next blocksize = prevblocksize * 0.9 → rounded to the nearest whole number
Flag = 1, If 0 < excess < 100% :
Next blocksize = prevblocksize
Flag = 2, If excess > 100% :
Next blocksize = prevblocksize * 1.1 → rounded to the nearest whole number
6.4 transaction types:
New Account - create a new Cyphae account/entity
Balance transfer - send Cyphae tokens between accounts
Request outgoing connection - request an outgoing connection from another account
Set account Node Provider - create account-node connection
Set outgoing connection fee - set account fee for requested outgoing connections
Toggle incoming connection wall - toggle on/of accounts ability to receive connections
Create outgoing connection - create an outgoing connection to another account
Transfer Incoming connection - transfer an eligible incoming connection to another
account
Archive account - disable account from any further state changes
Whitelist node - whitelist which accounts are eligible to form account-node connections
Set Outgoing connection limit - set limit for requested outgoing connections
Update account state hash - update state of an account
Update connection state hash - update state of a connection
7. Proof of delegated stake (security)
7.1 defining an eligible node (represented liquid stake)
Proof of delegated stake provides the foundation for security in Cyphae’s consensus mechanism. It is the main mechanism used to ensure each block is approved as valid by at least ⅔ of the network.
Each node’s eligibility to participate in consensus is first evaluated on a basis of each node's represented stake in the network. Each node's total represented stake is based on the collective balances of all accounts forming an account-node connection with the specific node. In order to be approved as an eligible node this total represented stake must exceed the network's minimum threshold. For the first million blocks this minimum represented stake will be 1% before decreasing to 0.1% and so on as the network scales.
7.2 potential node list
Once a node account exceeds the minimum threshold in required stake representation they may be verified as a potential eligible node through reading Cyphae’s most current state ledger. Once being approved as a potential node each potential node is given equal voting weight depending on the total number of potential nodes on Cyphae’s current ledger.
Ie. if there are 90 potential nodes each node has 1.1% voting weight
Since represented stake is based on account balances each node's represented stake is completely liquid and will fluctuate each block. This means that while keeping represented stake close to the minimum threshold does maximize node involvement per unit of represented stake it also creates high risk for unexpectedly going offline. As a result there is natural pressure for nodes to represent slightly over the minimum threshold as a buffer for stake variation while maximizing participation efficiency and resisting stake pool centralization.
7.3 basis for BFT - stake based security
Cyphae’s consensus is validated through a BFT based proof of delegated stake. This means as long as ⅔ of the defined potential nodes are participating honestly the system will continue to operate reliably. To allow third party verification each approved block contains a data tree containing signatures of the ⅔ of potential nodes that were involved in distributing the new block.
8. Proof of network presence (efficiency)
8.1 Communication vs Computation
In local compute systems efficiency is tied to computation, represented by the systems processing power and ability to process information. This means that in the case of local systems, optimizing computation power almost always leads to a more effective overall system(bitcoins POW). In the case of distributed networks, however, the prime factor for overall system efficiency is not based on local computation but rather based on each node's ability to communicate verifiable information effectively amongst the other nodes on the network. This is due to the fact that nodes must come together to function as a single computational system. In the case of distributed networking the mechanism in which nodes collaborate collectively is communication. For this reason, optimizing communication between nodes should be made a priority for the overall efficiency of processing information across a distributed system.
8.2 determining most efficient transaction ordering
Cyphae’s Proof of Presence is designed to find the most efficient path to distribute information across ⅔ of the network nodes (nodes defined through Proof of delegated Stake) while spreading block rewards fairly across active nodes. This is achieved through a race in network connectivity and collaborative reward incentives not centered around nodes “winning” but rather working together.
8.3 proof of presence racing
Once a node has passed the minimum stake requirement and acquires an adequate number of new transactions it begins to participate in the proof of presence race for the next block. This is done through the creation of a potential next block. Once a node has created a block from the transactions contained in its transaction pool it creates a hash for that block, activates its active proposal flag and attempts to send the new proposal hash to neighboring nodes to collect votes from ⅔ of potential nodes.
Upon receiving a new block proposal neighboring nodes first check to see if they have activated their own proposal flag. If they are already active for that block they compare incoming proposals with their own. If the incoming proposal has verifiably circulated more of the network through its list of node votes the neighboring node replaces their current proposal with the incoming proposal and signs it adding its vote to the proposal. If both blocks contain equal votes proposals are then evaluated on a basis of block transaction fees, block transaction diversity, proposal node presence(transaction involvement), proposal node stake, and if all are equal the node with the lower account number is selected. As these p2p comparisons occur across the network a majority of nodes end up relaying the same block proposal causing a transmission rate that mimics the same principles that drive virality.
Once a single proposal has been signed by ⅔ of potential nodes it is then converted into a valid block and distributed across the network to be added to the chain. If a node determines the new block to be invalid it flags the node that created it as malicious and reverts back to relaying its original proposal to re-attempt the proof or presence race for that block. In order for the chain to continue at least ⅔ of potential nodes must determine the block as valid so they are able to reach the minimum ⅔ vote threshold in the next block's proof of presence.
8.4 active node list
Block rewards are processed as part of the block confirmation protocol when a node receives a newly confirmed block. For each confirmed block on Cyphae there is a corresponding active node list. This active node list is used to provide a verifiable record of which nodes participated in the approval of the particular block. The nodes contained in each block’s active nodelist are determined by the votes that make up each block’s proof or presence (⅔ vote threshold). Once the active node list has been created and verified block rewards may be issued to active nodes.
8.5 network fees
A block's transaction related network fees are paid directly from each transaction sender account to the connected active node account, connected via an on-chain account-node connection. Transaction fees not tied to an active node (nodes not contained in active node list) are added to the new token reward pool that is distributed evenly amongst active nodes.
8.6 block rewards/incentives
After allocating each node their relative transaction fee related rewards a base reward is
distributed evenly amongst active nodes based on the size of that block's reward pool. The size of the reward pool is a combination of unclaimed transaction fees and newly released tokens. The number of newly released tokens is calculated using a decay function centered around remaining unreleased token supply and the total value of unclaimed transactions for that block.
8.7 Block reward function
All nodes in the active ⅔ of the network receive a block reward with the breakdown is as follows:
Active Node Block reward = Represented transaction fees + Base Block reward
Represented transaction fees = transaction fees in the block coming from accounts with
account-node connections to this node
Base Block reward = (unclaimed transaction fees + newly released tokens) / (# of active nodes)
Newly released tokens = unclaimed transaction fees / current token supply * ((max token supply - current token supply) / 2)
8.8 creating unique node revenue models
Thanks to the individualized relative node rewards coming from each active node's varying claimed transaction fees, nodes are able to set up unique revenue structures for incentivizing transactions. This is possible because the more fees spent by accounts connected to a certain node the more revenue that node generates. As a result nodes are able to take these rewards and reinvest them into creating incentives for rewarding the transactions of connected accounts. As an example this system may be used for unique cash back systems depending on the node your account is connected to.
8.9 attacks
8.9.1 Network Freezing
If a malicious node wished to prevent consensus from being reached they may flood the network with invalid data to hinder each node's ability to communicate with one another. Executed on a large scale this mechanism could be abused to freeze the network from advancing state. In this situation it is up to the node operators to host their nodes on new ips to avoid targeted package interference and reach consensus.
8.9.2 False Vote Proposal
If a node were to attempt to send a proposal with false votes they could possibly gain an
unexpected advantage in the proof of presence race. To mitigate this risk, both vote order and length are included as a part of the vote signature process when a node signs and votes on a new proposal. This ensures the entirety of the proposal vote list is fully authentic and third party verifiable in contents, origin, and order.
8.9.3 Collusion
Seeing as the network is designed to encourage node collaboration, collusion is a possible
security risk. Collusion on Cyphae, however, only becomes a risk as colluding nodes take up a larger percentage of the total potential nodes on Cyphae’s network. As long as ⅔ of potential network nodes remain honest each block will still be verified as valid by a majority of the network. In the case where collusion is suspected it is up to users and the community to utilize the open ledger to openly audit the network and take their support away from the malicious nodes before they reach ⅔ of the network through changing their account-node connections.
9. Verifying/Confirming blocks
9.1 verifying proof of presence solutions
When receiving a new block, prior to checking transaction validity, nodes are required to verify the block's proof of presence solution. The proof of presence solution contains a tree of block votes that may be used to verify the order and validity of the votes that made up the ⅔ active nodes for that block. After verifying the order of votes and vote signatures the node may then move onto verifying the transaction contained in the new block.
9.2 verifying transactions
Transactions are the state change requests made by account owners to update the network's state. Transactions are verified as valid based on the current network state, transaction contents, and the presence of a valid transaction signature. When receiving a new block each node validates the contents of that block locally to provide a distributed layer of security for preventing the continuation of invalid chains. After validating the block's proof of presence solution it then begins to evaluate the transactions contained in the block. This is done through attempting to process each transaction as if the block was valid. If any issues come up regarding transaction validity the node reverts back to its state before receiving the block and continues to search for a valid new block. If the node determines the block to be valid it updates its local network state to reflect the contents of the newly confirmed block and transactions and begins to work on the proof of presence race for the next block in the chain.
9.3 longest chain
If the network disagrees on the validity of a block each node simply continues working on the next block in the chain with the new block they deem to be valid. When attempting the next block’s proof of presence nodes will only be able to effectively communicate with the nodes that agree on the same most recent block. Since ⅔ of potential nodes are required for a valid proof of presence solution only the block validated by a majority of the network may be continued as a valid chain. This ensures that the contents of every block is checked as valid by at least ⅔ of network nodes and also prevents network forking.
10. Malicious nodes
10.1 detecting malicious nodes
Malicious nodes are detected automatically across the network through the transmission of invalid votes, blocks, and transactions, as well as through unwanted node spamming. After being detected they are added to a nodes locally contained malicious node list. Malicious nodes may also be determined manually through adding a node suspected to be malicious to the nodes locally contained malicious node list.
10.2 eliminating malicious nodes
Malicious nodes are eliminated in Cyphae through eliminating their ability to communicate
effectively with the rest of the network. This is done through each node referencing their locally contained malicious node list before relaying proposals, accepting blocks, or taking in node votes and potentially refusing communications. As more nodes in the network add a node to their malicious node list it becomes harder for the malicious node to create or sign block proposals, naturally eliminating the node's capabilities for network participation and rewards.