NO
(some products have integration with personal data)
| **YES** | | IP address not exposed | **YES** | **YES** | | Strong encryption (ECIES algorithm protection) |NO
(some products have weaker encryption algorithms)
| **YES** | | MiTM attack not possible (ECDSA protection) | **YES** | **YES** | | Message order is unchangeable | **YES** | **YES** | | Messages cannot be completely removed from data storage | **YES** | **YES** | | Consensus message integrity check | **YES** | **YES** | | Messages cannot be censored | **YES** | **YES** | | Full access from any devices if user has keys | **YES** | **YES** | | All data is stored in distributed network (you have no need to store data locally) | **YES** | **YES** | | File changelog (blockchain-based) | **NO** | **YES** | | Messages can be deleted for user, but stored in history of chat | **NO** | **YES** | | History is accessible only for chat participants | **NO** | **YES** | | Blockchain is not overflowed by messages transactions (this approach speeds up message distribution for users) | **NO** | **YES** | | Zero-proof for messages | **NO** | **YES** | As we can see, Distributed Storage Messenger offers more secured, controlled by participants and reliable approach for decentralized data exchange systems and networks. # ExC Store ExC Store is the most powerful tool for ExC DApp integration: ExC Store is a place, where ExC-based DApp can be shared and integrated with other apps and services, that are using ExC Framework. ExC Store includes several interactable API-s and ExDFS resources to ensure that every app, created with ExC Framework, has possible access to other user-created services. ExC Store offers several ways of interaction: * Coin-Token interaction: different apps with different internal tokens can work together via “quick exchange” mechanism from ExC Automated Exchange (see below); * Service integration: apps built as services can be integrated into other apps via standardized APIs. User-created payment service integrated in other apps can serve as example; * Data integration: single-profile authorization and peer-to-peer data exchange between apps. Apps can interact with ExC user profile to extract basic data for authorization and share their unique-named fields of user profile. This type of interaction serves for unification of access and data management; # ExC Tokens and Automated Exchange Tokens are created and used similar to other cryptocurrency token platforms (such as Graphene). Token features include all ExC base coin features as blockchain snapshots, branched chains, fast search and PoS rewards. This features can be enabled by token owner. Main difference is that fee from token transactions is charged in tokens. This improvement helps to distribute token faster and popularize it. User will have an opportunity to exchange all tokens at distributed exchange integrated in ExC platform. ExC Automated Exchange is ExC-based, integrated exchange service, built on DeFi principles. Every ExC-based token (ExT) has the possibility to enable exchange pairs with other ExT-s. Only requirement for token creators is to maintain a liquidity pool for desired exchange pairs. Also, ExC Automated Exchange is community-driven, so everyone can participate in liquidity pool maintenance via DeFi farming. ExC Tokens are powered by ExtraChain smart-contracts. Smart contracts are made from simple and advanced code blocks, inducing visual simplicity united with complex approach. Simple Code Blocks are same as in traditional block diagram: * Integer value; * Double value; * Bool value; * Plus block; * Multiply block; * Minus block; * Equation block; * Array block; * Map block; * "OR" block; * "AND" block; * "NOT" argument for block; * "RATIO" block (block defines ratio between two Integer or Double values); Advanced Code Blocks are more complex but flexible for more high-level development: * "Creation" block (this block is predefined to ensure compatibility with other ExC tokens and services): * Input: * Type - ExT / ExNFT / ExService; * Owner address; * Token holder address (if needed to send tokens to distributor at creation); * Total token amount (total supply); * Token minting/staking slot (here TM/SF block should be connected); * **(ExNFT only)** Unique link to ExDFS file; * Output: * All functions of smart contract should be connected to "Creation" output; * "Transfer From/To" block (this block is predefined to ensure compatibility with other ExC tokens and services): * Input: * Sender Address (with checkbox - if needed, service provider can do transfers from sender to service provider address. Disabled by default); * Receiver Address; * Amount; * Data Payload; * Transaction condition slot (used to control transaction process); * Output: * Result - JSON with success/failure of transaction; * "Exchange Processing" block: * Input: * First token address; * First token amount; * Second token address; * Map of token addresses and "RATIO" blocks (defines exchange rules for token); * Output: * JSON with second token address and amount; * "Token Minting/Staking Formula" block (TM/SF): * Input: * Total circulating amount of token; * Total amount of token holders; * **(Minting-specific)** Seed value (complexity) for formula; * **(Staking-specific)** Total amount of User-locked tokens; * **(Staking-specific)** User-specific value of locked tokens (user address will be used); * **(Staking-specific)** Transaction amount as seed for staking (Transaction ID will be used); * EVM-code block, defining the Minting/Staking formula. * Receiver address; All parameters except Seed value and TM/SF-defining block will be taken from blockchain automatically. * Output: * JSON structure with amount and receiver of token to be translated to transaction. * "Custom Code" block: * EVM code function, defined by developer, where input and output slots are defined by user. According to best practice, it is advised to return integer or bool value, or JSON structure, if required by predefined Code blocks. # ExConsensus ExC consensus is an advanced consensus algorithm aimed to connect and unite Proof-of-Stake & Proof-of-Data ideology with high speed, integrity and portability of Directed Acyclic Graph data structure. ExC consensus is based on block data checks and aimed to form consistent and stable block chain between two genesis blocks. Each produced transaction transfers to network neighbors (“verifiers”) and goes through verification process made by them. # Transaction Verification Algorithm (TVA) Transaction Verification Algorithm (TVA): 1. Proof-of-Existence of sender and receiver 1. Check if address exists in local Actor DB (should be done for sender and receiver); 2. Check digital signature of transaction (done for sender) via EdDSA algorithm; 3. Check sender status (user or smart contract); If at least one step fails, transaction will be denied. 1. Proof-of-Existence of entities: 1. Sender and receiver balances (in blockchain); 2. Edited directories and files (in ExDFS); 2. Proof-of-Allowance: 1. Sender and receiver balances are >= 0 after transaction (in blockchain); 2. Edited or created file is in ownership of sender or sender is marked as editor for the file (in ExDFS); If all proofs are true, transaction is verified and put into block.  Each verifier put its ID and signature in the block. Block is distributed by verifiers via network. Network neighbors of verifiers check created blocks and approve their consistence. They become “approvers”. # Block Prove Algorithm (BPA) Block Prove Algorithm (BPA): 1. Check digital signature of block via EdDSA algorithm; 2. Check hash link to previous block; 1. If hash link points to local last block – proceed; 2. If hash link points to other block – stop Block Prove and start Block Merge; 3. If block with same number is already in local blockchain, stop Block Prove and start Block Merge; 4. If received block is new, check each transaction in block via TVA; 5. If TVA check is successful – add approver signature and distribute approved block. Block needs to be approved by at least 2 approvers to become “mature”.  # Block Merge Algorithm (BMA) Block Merge Algorithm (BMA): If BMA is started, then one or more blocks in local blockchain can be corrupted or incomplete. Also, new block can have malicious data. Thus, approver must make deep scan of block data. 1. Compare received and old block data. 1. If data hash is different – compare block data and detect new transactions. 2. If there are no new transactions: 1. And previous block hash is same – drop received block. 2. And previous block hash is different – stop BMA and start BPA; 2. Check detected transactions with TVA. If transactions pass TVA, new block with added transactions is produced and distributed. New block can trigger chain of BMA calls to make consistent chain for each network unit.   # State Snapshot Algorithm (SSA) aka “Genesis Algorithm” State Snapshot Algorithm (SSA) aka “Genesis Algorithm”: State Snapshot Algorithm produces Genesis Blocks each 100 blocks. Genesis Blocks hold Actors’ balances data and serves as state backup and foothold for devices in “Fast Blockchain” mode. Genesis block production algorithm: 1. Find last Genesis Block and load IDs and balances; 2. Collect all new balances and make all changes from last Genesis Block to current block; 3. Merge collected data with loaded data; 4. Distribute new Genesis Block; If device receives new Genesis Block, then BPA starts, but only for previous and new Genesis Block.  # Additional Features ExConsensus also includes DAG and Proof-of-Stake features. DAG features: * Possible existence of branched chains; * Multiple genesis blocks; * Each block and transaction can have more than one connection (token creation and transactions, genesis blocks); * Non-limited block size; These features allow faster search and smaller amount of blocks needed to interact with blockchain. ExC requires 100 blocks and genesis block (blockchain snapshot) to securely interact with main chain. PoS features: * Cashback – up to 80% of transaction fee can be returned to tx sender, if other nodes prove that only 2 nodes from required 10 made similar block check and proved its coherence. * Rewards – PoS rewards are paid from each proved transaction. Users can stake their coins and receive rewards based on formula:  *StakingModifier* is a control coefficient and equals to 0.5 * Staking scheme applies to main coin and all tokens (if this feature is enabled by creator); # ExtraChain Indicators * Transaction bandwidth: 2321 – 3242 tx/sec * Token creation time: 1 sec * Block creation time: each 2 sec * Fee: from 0,2% to 1% (see “Cashback”) * Non-personalized transactions: yes * Personalized transactions: yes # Appendix A. Terms and Theory **Distributed architecture** – software and network architecture design approach, where each user node is connected to others, aimed to bring (through one-rank connections) stability and high fault tolerance to the network. **Directed acyclic graph** – finite directed graph with no directed cycles. DAG is a directed graph that has a topological ordering, a sequence of the vertices such that every edge is directed from earlier to later in the sequence. DAGs allow for multiple chains of blocks to co-exist and interconnect while never forming an edge with a parent node. Nodes can exist in parallel, as long as information is directed in the same way. There are no blocks in DAG-based chains, each node is transaction. **Blockchain** – organized directed database, bound by cryptography and Merkle tree data structure. By design, a blockchain is resistant to modification of the data. It is "an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way". For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority. Although blockchain records are not unalterable, blockchains may be considered secure by design and exemplify a distributed computing system with high Byzantine fault tolerance. Decentralized consensus has therefore been claimed with a blockchain. **Merkle tree** – a tree in which every leaf node is labelled with the cryptographic hash of a data block, and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes. Hash trees allow efficient and secure verification of the contents of large data structures. **Actor** – an acting unit of network, that: 1. Has “public-private” key pair; 2. Is verified by other network actors; 3. Can send and receive transactions; 4. Can load data into network; Actor entities examples: user, smart contract, bot etc. **Proof-of-Existence** – a concept aimed to verify existence of real world object or digital unit via digital algorithms or systems (like blockchain). This concept is used to: * secure the ownership of real-life and digital entities; * protect property rights; * prove the existence of selected entities; * allow fast and decentralized verification of all named above **Non-fungible token (NFT)** is a unit of data on a digital ledger called a blockchain, where each NFT can represent a unique digital item, and thus they are not interchangeable. NFTs can represent digital files such as art, audio, videos, items in video games and other forms of creative work. **Genesis Block** – a blockchain unit that holds state of blockchain. Bitcoin- and Ethereum-like blockchains have Genesis Blocks as initial blocks of chain, holding initial addresses and their balances. **Fast-Blockchain mode** – ExC operation mode, when device downloads only part of blockchain from current block to last Genesis Block. This mode is made for devices with hard limit of memory and users, who want to start network operation faster. **Full-Blockchain mode** – ExC operation mode, when device downloads full blockchain. This mode requires more memory, but grants possibility to make faster checks during all prove algorithms. # Appendix B. ExC Application in example According to our research, decentralized social network (DSN) can be considered as best example of ExtraChain technology integration. All social networks (SNs), that are in use in different countries and social groups, are tightly integrated in everyday life of such social groups. Users build their life routine via social networks, they: * Contact each other via messengers; * search and retrieve valuable information from public posts; * look for common thoughts and form socially active groups; * Buy and sell their goods and services; For many SN-users, social networks become high-priority work platforms: * Digital artists; * Bloggers; * Reviewers; * Streamers; * Models; * Photographers; * Musicians; * etc. They are independent groups of creators, who require more direct contact between content producer and content consumer. But popular and widely used social networks have not so much to offer such type of users: * Slow feature development; * Low personal data security; * No, very simple or inaccessible value exchange instruments (trade platforms, payment systems etc.); * High censorship probability; Content creators need to use many platforms to build successful SN-business and/or develop their own personal brand. For example, photographer and artist can use Instagram or Facebook to popularize their works and then direct fans and interested users to Patreon, where exclusive content is sold. This production chain seems to work good, but social network with integrated monetization system (leveled subscription, direct sale of content etc.) grab and hold user attention more effectively, up to 45%. All these problems made social request for new type of social network architecture: all-in-one instrument, built on community ideas and rules, controlled by clear algorithms and collective decisions. So, ideal social network must be: * Decentralized – data storage and user interactions must be peer-to-peer; * Personalized – each user must have instruments to be successful in SN-business; * Understandable – social network parts must be simple and native for users; * Changeable – user must have instruments to affect network state (voting, ranking system etc.); * Universal – network must include such tech and social decisions, that can be useful for different groups of content creators (different content production and delivery methods, varied monetization plans); All these requests can be fulfilled with two main technologies: blockchain and decentralized file storage. Let’s take a closer look at ExC-based solution. ExC Blockchain usage In social network, blockchain can be used in various ways: * Security instrument (authorization, verification); * Personal data protector; * Authenticity verifier; * Universal access key distributor; * Proof-of-Ownership guarantor; * Value exchange provider; At ExC-based social network, each possible blockchain application is implementable and have its own place. Let’s start with: **Security** As other blockchain-based networks, ExC social network uses authorization via private/public keypair and identification via user id made from keypair. This gives high level of privacy and protection from personal data phishing, network activity and transaction scan. Also it creates a basis for implementation of higher levels of security, including personal data security in distributed file system and data exchange channels security. ExC implements Elliptic Curves Cryptography and Diffie-Hellman key distribution algorithm. This approach allows implementations of two possible scenarios: * Main asymmetric key security (general authorization, transaction verification, ExDFS actions authorization); * Session symmetric key security (chat security, content streaming security etc.); The best example of session key usage is social network chat. Session key is created at chat initialization and is distributed by chat creator to all chat participants via Diffie-Hellman key exchange algorithm, to ensure that only participants will receive session key. Each new user joined receives key in invitation network packet. When user leaves, chat participants save old session key and generate new one, to ensure that new chat interactions will not be accessible for former participants. So, private/public keypair is universal key for all possible interactions in ExC-based social network. Other main usage of ExC blockchain is: #### Proof-of-Ownership Blockchain can be used as verifier of “Ownership” and “Transfer of Ownership” procedure. Fungible or non-fungible tokens can be implemented via ExC Token Module to reflect all possible interactions between users of social networks. This can be: * Trade operations (digital art, photos, real-world goods etc.); * Community rewards and tokens (useful for bloggers and streamers for community events and challenges); * Internal value providers for ExC-based products; * NFTs, depicting real-life objects and goods for automated and manual auctions; * NFTs, encoding digital art objects; Each transaction in ExC blockchain is secured by previously named algorithms and is protected blockchain transparency, thus it is not possible to issue fake NFTs or tokens. And no social network features are possible without data exchange between users. This way we move to ExDFS and the role of this technology in social network. **ExDFS usage** ExDFS is a distributed file system that is core feature and main advantage of all-in-one decision, offered by ExtraChain DAO Framework. All data in social network can be grouped by user id and type of content and organized in directory tree. Each “tree” is supported by “card file”. This files contain file path and name with hashed value of file. And each hash is made from hash of previously created file and value of current file. This way all files in user directory save their consistency and order.  Each newly created file receives its own small history of changes organized in chained structure via hashes, same way as main “card file”. This history of changes is called **Historical Chain**, as explained at [ExDFS page](/overview/distributed-file-system). So, allowed users can see file history of changes and use this feature in different situations as, for example, restoring own deleted messages. Messenger module of social network is built completely around Historical Chain. As it was said before, each unit of stored data is file. In ExC-based social network, messaging history is stored in Historical Chain structure, in secured and consistent way. Unauthorized changes are not possible, because Historical Chains are going through collective approve process, same as ordinary transactions in main ExC blockchain. The only difference is proving rules: * user must have right to change file; * change must be in right position relative to other changes; * hash must be true; If change is correct and is approved by randomly chosen approver nodes, the change is added to Historical Chain and chat participants receive new message. **Summary** ExtraChain DAO Framework offers new approach to decentralized applications architecture and development, based on two main technologies: ExC blockchain and ExDFS. First one offers distributed approach to user interactions in the network (trading, voting, value production and consumption) and second one offers distributed approach to storage architecture and development of a product. ExtraChain gives opportunity to build small and big communities based on ideas of cooperation, equality and public voting, which leads to healthy and strong interactions between all parts of user-made organizations and communities.