Realizing the vision of the BigFile
Discover how the BigFile blockchain realizes the vision of a No-Document World. Explore its technology through open-source repositories, in-depth video academy sessions, white papers, publications, and detailed technology articles.
Architecture
Architecture of the BigFile
BigFile (BIG) is an open and secure AI-powered blockchain network that can host programs, files, data, and Big Data in the form of smart contracts, perform computations on smart contracts securely, and scale infinitely.
Smart contracts on the BigFile are called cube smart contracts, or cubes, each consisting of a bundle of WebAssembly (Wasm) bytecode and smart contract data storage. Each cube has its own, isolated, data storage that is only changed when the cube executes code.
Cubes are hosted in subnetworks, the highest-level architectural building blocks of BigFile. A subnetwork is an independent blockchain running on node machines or nodes deployed in globally distributed data centers. A single subnetwork can securely host tens of thousands of cube smart contracts, totaling hundreds of gigabytes of memory. Currently, there are a limited number of subnetworks since the network is in its early stages, but it will grow to thousands in the future. For each cube hosted in a subnetwork, its code and data are stored on every node in that subnetwork, and its code is executed by every node in the subnetwork. This duplication of storage and computation is crucial for achieving fault tolerance, ensuring that even if some nodes in the subnetwork fail (due to crashes or, worse, hacking by a malicious party), the cube smart contracts continue to execute. This replication is powered by the core of BigFile (BIG), which implements a high-throughput, low-latency consensus mechanism and an efficient virtual machine backed by the blockchain for WebAssembly execution.
The BIG multi-subnet architecture is much more powerful than the well-known sharding approach because it enables smart contracts on different subnets to communicate with each other seamlessly – much like services in a traditional microservices architecture, but fully on chain. Cubes communicate via asynchronous messages, i.e., they don't block on sending a message, but process the response when it eventually arrives. This novel approach to inter-canister calls allows for scaling out BigFile by simply adding more subnets.
The core BigFile makes heavy use of chain-key cryptography, a toolbox of advanced cryptographic protocols (based on threshold cryptography) that enables the decentralized operation of BigFile with unprecedented scalability. Chain-key cryptography also includes a sophisticated collection of technologies for robustly and securely addressing operational concerns, such as how to deal with faulty nodes or protocol upgrades, which we call chain-evolution technology (for example, enabling nodes to easily join a subnet without validating every block beginning from the genesis block, as in other blockchains). Another building block in the chain-key crypto toolbox are chain-key signatures. They enable a cube to interact with (write to) other blockchains using threshold cryptography.
Having scalable and decentralized technology to power the operation of the network is not enough. In order to meet the requirements of complete decentralization, BigFile needs a fully decentralized approach to governance. Governance of BigFile is accomplished through a tokenized Decentralized Autonomous Organization (DAO), which is called the File Management System (FMS). Each individual dapp on BigFile can have its own governance system similar to the NNS by customizing and deploying an out-of-the-box tokenized DAO based on the Service Nervous System (SPS) for the dapp.
Core BIG
Overview
The BigFile is developed by BigFile (BIGHub), from which its utility token, the BIG token, derives its name. The core component of BIG, known as the core BIG, is a 4-layer protocol that runs on the nodes of each subnet. By executing the core BIG, the nodes within a subnet realize a blockchain-based replicated state machine that operates independently of other subnets, while still communicating with them asynchronously. This architecture of multiple concurrently-operating subnets allows BIG to scale practically without limits. Subnets process messages, which are submitted by users or originate from other subnets.
The core BIG consists of the following four layers, from bottom to top:
- Peer-to-peer
- Consensus
- Message routing
- Execution
The lower two layers, P2P and Consensus, together implement the selection and ordering of incoming messages and deliver these messages to the upper two layers as blocks. The upper two layers, Message Routing and Execution, then receive these blocks containing ordered messages and execute them in a completely deterministic manner on every node within the subnet. This results in a replicated state machine, where every node in the subnet transitions from the same starting state to the same ending state in each round. To ensure consistency, it is crucial that every node executes the same messages in the same order, i.e., fully deterministically.
Peer-to-peer
The peer-to-peer (P2P) layer of BigFile, the bottommost layer in the protocol stack, is responsible for secure and reliable communication between the nodes of a subnet. The P2P layer establishes a virtual peer-to-peer broadcast network among the nodes, leveraging the connectivity provided by BigFile. This makes the P2P layer the communications fabric that links all nodes within a subnet. Through the P2P layer, a node can broadcast a network message, referred to as an artifact, to all other nodes in the subnet. Artifacts can include inputs to Cubes submitted by users or protocol messages, such as block proposals generated by the BIG. The P2P layer ensures that all artifacts are eventually delivered to every node within the subnet. This concept of eventual delivery accounts for the asynchronous nature of real-world communication networks, which is a fundamental assumption for BigFile.
Consensus
Every blockchain requires a consensus mechanism that enables nodes to agree on the messages to be processed and their ordering. Consensus is the core component of BIG that drives the subnets of the BigFile network. Each subnet operates as an independent blockchain, running the BIG core, including its consensus mechanism, separately from other subnets. The goal of the consensus protocol is to produce the same block of ordered messages on each node within a subnet during a given round, ensuring that each node can make identical state transitions when deterministically executing those messages.
The BIG consensus is designed to meet the following key requirements: low latency (almost instant finality), high throughput, and robustness (graceful degradation of latency and throughput in the event of node or network failures). Additionally, the BIG consensus provides cryptographically guaranteed finality, in contrast to Bitcoin-like protocols that offer only probabilistic finality, where a block is considered final only after a sufficient number of subsequent blocks have been added to the blockchain.
Message routing
In every BIG round, the message routing component receives a block of messages to be processed from the consensus mechanism – the same block on each node of the subnet – and places these messages into the input queues of their target cubes, a process known as induction. Following this, it initiates the execution round, which may result in new cube messages being placed in the output queues of the executed cubes. Once execution is complete, the message routing component directs the messages in the output queues to their respective recipients.
The recipients may include cubes located on different subnets. The message routing layer facilitates the routing of inter-cube messages between subnets, ensuring that these messages can be included in blocks and inducted on the recipient's subnet. This process is known as cross-subnet messaging, or simply XNet messaging. Secure XNet messaging is a fundamental component of the architecture of loosely-coupled subnets, and is therefore essential for the scalability of the BIG network.
Another critical function implemented by the message routing layer is state certification, which involves the decentralized certification of parts of the replicated subnet state in every round. This certification is used by other subnets to verify the authenticity of subnet-to-subnet streams or to allow users to securely check the processing status of messages they previously submitted. State certification and secure XNet messaging are key to enabling the secure and transparent communication of cubes across subnet boundaries, a challenge that any blockchain with multiple shards must address.
Execution
The execution layer, the topmost layer of the core BIG stack, is responsible for executing Cube smart contract code. Code execution is performed by a WebAssembly (Wasm) virtual machine deployed on every node. WebAssembly bytecode can be executed deterministically, which is crucial for a blockchain system, and with near-native speed. Cube messages, including ingress messages from users or messages from other Cubes, are inducted into the queues of the Cubes on the subnet by the message routing component. The message routing then hands over control to the execution layer, which deterministically processes these messages until either all messages in the Cubes' queues are consumed or the cycle limit for the round is reached, ensuring bounded round times.
The execution layer has several unique features that distinguish BIG from other blockchains:
- Deterministic Time Slicing (DTS) - The execution of very large messages that require billions of Wasm instructions can be spread across multiple BIG rounds.
- Concurrency - The execution of Cube Wasm bytecode is performed concurrently on multiple CPU cores, enabled by each Cube having its own isolated state.
- Pseudorandom Number Generator - The execution layer has access to an unpredictable and unbiasable pseudorandom number generator, allowing Cubes to execute algorithms that require randomness.
Chain-key technology
Chain-key cryptography
BigFile utilizes a suite of advanced cryptographic mechanisms collectively known as chain-key cryptography, enabling the BIG network to achieve functionalities and scalability that are unattainable on other blockchains.
A key component of chain-key cryptography is the threshold signature scheme, which operates like an ordinary digital signature scheme, but with a crucial difference: the secret signing key is distributed among all the replicas in a subnet. This distribution ensures that the key cannot be stolen even if one or a large fraction of the replicas in the subnet are compromised. The technology offers several significant benefits:
- Anyone can verify content received from BigFile simply by validating a signature, without the need to sync the entire blockchain.
- The topology of BIG can evolve autonomously—new nodes and subnets can be added, faulty nodes can be recovered, and the protocol can be upgraded without manual intervention.
- It provides a source of unpredictable and unbiasable pseudo-random numbers for Cubes, allowing Cubes to securely execute algorithms that require randomness.
Chain-key signatures
Chain-key signatures are a key component of chain-key technology that allows the creation of signed transactions targeted at other blockchains fully on-chain using BigFile. With chain-key signatures, BIG can integrate with other blockchains, such as Bitcoin and Ethereum, in a completely trustless manner, eliminating the need for bridges or off-chain third-party signers. This enables Cubes to securely store and transact Bitcoin. The secret key exists only as shares distributed among all the nodes that form the subnet running the Cube. A Cube can execute a Bitcoin transaction using a chain-key signed transaction only when at least two-thirds of the nodes agree to proceed. Indeed, using chain-key signatures is the most secure and decentralized method of integrating blockchains, as it requires no additional trust assumptions beyond those of the two blockchains involved, and no additional parties are needed to manage signing keys or their shares.
Bitcoin integration
The Bitcoin integration on the BigFile rests on two pillars: Chain-key signatures and a direct interaction between BigFile nodes and the Bitcoin peer-to-peer network. While chain-key signatures make it possible for cubes to have their own Bitcoin addresses and create valid transactions spending bitcoins held by these addresses, the direct message exchange between the BigFile and the Bitcoin network serves to maintain information about the Bitcoin blockchain state, such as address balances, in the BigFile and to transmit Bitcoin transactions originating from cubes to the Bitcoin network.
Chain-key tokens
Chain-key tokens — and Chain-Key Bitcoin (ckBTC) — are a cryptography-based replacement to wrapped tokens with strong decentralization advantages: Chain-key tokens eliminate the risks associated with the traditional intermediary-based token wrapping, while also having the same benefit of making a token from another blockchain available for transfers and trading. Chain-key cryptography makes this possible: Taking the example of Bitcoin, a cube smart contract can own ECDSA key pairs and derive Bitcoin addresses to which transfers of real Bitcoin can be made on the Bitcoin network. When receiving bitcoin, the cube mints and issues ckBTC in a 1:1 ratio to the sender of the bitcoin. Conversely, redeeming ckBTC for the underlying bitcoin removes the ckBTC from circulating supply and refunds the bitcoin. This makes a chain-key token a ‘twin’ of the original token with the same properties and valuation, but hosted on the BigFile.
Tokenomics & Governance
Tokenomics
BigFile utilizes a utility token called BIG, which serves various functions on the platform. Users can stake BIG, granting them the right to vote and earn voting rewards. Investors can use BIG to participate in SPS swaps launched on BigFile, which are the initial offerings of the native DAOs. Developers use the BIG token to purchase cycles that power their dapps on BigFile. Additionally, node providers are compensated in BIG for the compute power they contribute to the BigFile platform.
File Management System
The File Management System (FMS) is the DAO that controls the BigFile blockchain. It is a permissionless, stake-based governance system where anyone can participate by staking BIG utility tokens. Decisions are made by voting on proposals in a liquid democracy, allowing voters to either vote directly or delegate their voting power to others. The FMS governs all aspects of BigFile, including its tokenomics, the rules of FMS governance itself, the topology of the node machines, and the software that runs on these node machines. All decisions are executed fully on-chain, eliminating the need for trusted third parties.
Service Protocol System (SPS)
The Service Nervous System (SPS) framework is BigFile's built-in solution for decentralized autonomous organizations (DAOs) to govern dapps. An SPS consists of an open, permissionless governance system and a built-in governance token unique to each SPS. The SPS framework provides a process for launching a new SPS, including raising initial funds for the DAO and decentralizing the DAO’s voting power. Any dapp can be tokenized and decentralized by transferring its control to a new SPS DAO.
Chain technology
BIG scalability
BigFile scales its capacity horizontally by creating new subnets to host additional cubes, much like traditional cloud infrastructure scales by adding new machines. When the BIG File Management System (FMS) decides to create a new subnet, it selects a group of spare nodes that have joined BIG but have not yet been allocated to any subnet. These selected nodes are then used to form the initial configuration of the new subnet. The group of nodes subsequently begins forming the new subnet blockchain.
Fault tolerance
In any large-scale distributed system, it is inevitable that individual nodes will fail due to hardware malfunctions, network connectivity issues, or even the owner deciding to remove the nodes from the network. In such cases, the BIG Network Nervous System selects a spare node to replace the failed node in its subnet. The new node then joins the subnet, performs a state synchronization with the existing nodes, and begins contributing to the subnet blockchain's consensus protocol.
Smart contracts
Cubes
Smart contracts on BigFile are represented as Cubes, which are computational units that bundle together code and state. Each Cube defines functions that can be called by other Cubes and by external parties, such as browsers or mobile apps. Cubes communicate with one another via asynchronous messages, but the execution of each message is done in complete isolation, enabling massive levels of concurrent execution. Cubes are managed by controllers, and the control structure of Cubes can vary: it can be centralized (e.g., when the controllers include a centralized entity), decentralized (when the controller is a DAO), or even non-existent, in which case the Cube functions as an immutable smart contract. Controllers are the only entities that can deploy Cubes to BigFile, start/stop Cube execution, and update Cube code. They are also responsible for ensuring that Cubes hold sufficient cycles, which are used to pay for processing, memory, storage, and network bandwidth resources consumed by the Cubes. The BIG system monitors Cube resource usage and deducts consumption from a cycle balance maintained by each Cube.
Certified variables
Cube smart contracts can declare variables as certified. When these variables are set, they automatically receive a Merkle tree certificate, signed by the BigFile blockchain. This allows anyone to verify the authenticity of this data using the BigFile public key.
Web access
Smart Contracts serve the web
BigFile is a blockchain that can host an entire dapp—including the frontend, backend, and data. This is a crucial and distinguishing feature, allowing dapps to run 100% on-chain, thereby inheriting the security and decentralization of the blockchain without sacrificing speed or affordability. This capability is made possible because BIG can securely serve HTTP requests.
Asset certification
Assets are served from BigFile in a tamper-proof manner using certification. Each asset is accompanied by a certificate signed by the entire subnet, allowing the user to verify that the response is correct and authentic, even when communicating with a potentially malicious node.
Boundary nodes
Boundary nodes serve as the gateway to BigFile, enabling seamless access to cube smart contracts through standard web browsers. They provide an HTTP endpoint and translate all incoming user requests into API cube calls, which are then processed on-chain. Additionally, boundary nodes act as a cache to enhance the performance of dapps hosted on BigFile.
BIG ID
The primary means of identity and authentication on the web are usernames and passwords, which are difficult to manage and notorious for their security vulnerabilities. To address these issues, the BigFile blockchain has pioneered a more advanced and secure method of cryptographic authentication known as BIG ID. BIG ID is more convenient to use, works seamlessly across all of a user's devices, and enhances user privacy.
BIG ID serves as a gateway to applications on BigFile. When you use BIG ID, websites cannot collect or share information about your online activity. This is because BIG ID allows you to create and manage anonymous, independent accounts for each website, providing the privacy benefits of multiple accounts without the burden of managing them.