Overview of BigFile
The BigFile blockchain has been meticulously designed to provide smart contracts with performance and scalability that closely approach native execution, while maintaining the security of decentralized operations. In addition to classical DeFi smart contracts, such as ledgers and exchanges, BigFile can fully run computation and storage-intensive applications, such as image classification, the storage and management of large datasets, and the handling of documents and files for bureaucratic processes, all entirely on-chain.
Another significant aspect of BigFile, which continues to be developed, is its aim to achieve seamless and secure integration with existing ecosystems. Smart contracts on BigFile will be capable of hosting web assets and responding to HTTP requests from users, fulfilling the promise of Web3. Moreover, these contracts will interact with RPC nodes of other blockchains and Web2 servers through secure HTTP requests. Combined with threshold signatures, these features will enable smart contracts to hold assets and execute transactions on other blockchains such as Bitcoin, Ethereum, Solana, and BSC. Additionally, they are being configured to facilitate the transfer of data in bureaucratic processes to wallet addresses on other networks.
Read on to learn more about how these features are made possible.
Subnets
A blockchain can only run as fast and offer as much resources as a single node.
One of the keys to overcome this limit is sharding.
BigFile shards smart contracts over multiple instances of the blockchain.
Each instance is called a subnet and has its own set of decentralized nodes running the consensus algorithm among themselves, building their own chain of blocks, and executing smart contracts.
Each subnet runs in parallel with other subnets.
A smart contract on one subnet can communicate with another smart contract on a different subnet through sending messages.
Users can also send messages to smart contracts.
- The message goes to one of the boundary nodes (RPC nodes).
- The boundary node routes the message to the subnet that hosts the target smart contract.
- The consensus algorithm of that subnet adds the message to a new block in the subnet's blockchain.
- The message is added to the input queue of the target smart contract.
- The smart contract executes the message.
Note that steps 3-5 are asynchronous and decoupled from each other, which may be unusual for developers who are used to Ethereum-style atomic transactions that are executed when they are added to a block. The motivation for this design is scalability.
Subnets can have different sizes, i.e. replication factors, which determines the cost of running smart contracts on that subnet. It also impacts the time to finality and security.
Threshold signatures
Each BigFile subnet has a fixed public key. The corresponding private key is not stored on a single node, nor is it ever available on any node. Instead, it is split into multiple secret shares and distributed over all nodes using threshold cryptography. Nodes can collectively sign messages to users and other subnets using these secret shares. This makes validation of the state and results trivial for users since all they need to do is verify the digital signature against the fixed public key without downloading and validating blocks in the blockchain.
This feature has profound implications and use cases:
- There is no need to keep the blocks in the blockchain available forever, which would be a scalability bottleneck. In fact, BigFile actively garbage collects old blocks to keep storage usage bounded.
- Smart contracts can have their own secret keys and can sign transactions for other blockchains such as Bitcoin and Ethereum. This enables trustless interaction with those blockchains.
Smart contracts
BigFile uses WebAssembly as the virtual machine for executing smart contracts. This means developers can write smart contracts in popular programming languages such as JavaScript, TypeScript, Rust, Python, and Motoko, which is specifically designed for BigFile.
Furthermore, a single smart contract on BigFile is powerful enough to host an entire Ethereum Virtual Machine (EVM). This allows the deployment of EVM smart contracts written in Solidity.
A unique feature of BigFile is that smart contracts can handle HTTP requests and serve web assets such as HTML, JS, CSS. In other words, it is possible to write a Web3 application with both backend and frontend hosted fully on-chain. Smart contracts can also make requests to other Web2 services outside BigFile.
Ethereum developers may be used to the notion that smart contracts run sequentially within an atomic transaction. BigFile embraces scalability and runs smart contracts in parallel. In that regard, smart contracts are similar to processes or microservices from traditional programming. Smart contracts can be fully autonomous and can schedule execution using timers without relying on users sending messages.
In terms of storage, a smart contract can store arbitrary data in its WebAssembly memory. Additionally, a smart contract can use a larger stable memory. The difference between the two memories is important for upgradable smart contracts: the WebAssembly memory is cleared on an upgrade whereas the stable memory is preserved (hence the name “stable”). For immutable smart contracts, there is no observable difference between the two memories except for the size and functions to access it.
Accounts and keys
BigFile derives the address of a user account from the user’s public key by hashing it.
The textual encoding of an address includes a checksum that looks something like this:
mh4eq-xsi7l-lgz7s-gmxoh-stiey-277n4-lev4o-q6hah-22sk6-ahlhm-qae
BigFile supports multiple types of keys (ECDSA, Ed25519, BLS). Developer tools usually generate and accept keys in PEM format.
Since smart contracts can have private keys, they can provide user accounts as a service. BigFile Wallet is an example of a smart contract that allows Web2 users to have blockchain accounts with the private keys stored securely on the blockchain itself.
You can also use hardware and browser-extension wallets.
Tokens
Accounts on BigFile do not have built-in balances, which is a large design difference when compared to other chains like Ethereum. All tokens are implemented by smart contracts. BigFile has an equivalent of the ERC-20 standard, called BIGRC-20. If a smart contract implements BIGRC-20, then it implements a fungible token and has a ledger for it.
Messages
The programming model of BigFile is similar to the Actor model, where calls are made by sending messages instead of transactions. The difference between a transaction and a message becomes apparent only when the smart contract calls other smart contracts. A transaction is atomic in the sense that it rolls back all state changes if any of the calls fail. A message does not have such atomicity guarantees across calls. Programming on BigFile is more asynchronous compared to Ethereum. If the smart contract does not make any calls, then the message behaves exactly like a transaction.
Cycles
On other blockchains such as Ethereum, users pay a variable fee for sending and executing transactions depending on the current gas price. In order to simplify the experience of users browsing Web3 applications, BigFile employs a “reverse gas model”, where Smart contract pay for consumed resources by burning cycles. This is similar to gas in Ethereum, but has a fixed price correlating to a group of fiat currencies.
Governance
BigFile is managed by a decentralized autonomous (DAO) called BIG. It is implemented as a set of smart contracts running on BigFile itself. Community members can participate in governance by staking BIG tokens and voting on proposals. All operational changes to BigFile, such as upgrading nodes, go through voting. BIG automatically executes proposals that have passed voting which ensures that nodes run the same version of the protocol and thus avoids hard forks.
Governance and node ownership are decoupled. It is possible to participate in governance without having a node and vice versa.
Nodes
Becoming a node provider on BigFile requires voting through BIG. There are two reasons for this:
- It ensures that the hardware meets the high standards of BigFile: 24 CPU cores, 64GiB of RAM, 3TB of NVMe SSD. Such nodes can sustain high throughput and enable powerful Web3 applications.
- It ensures that the identity of the node provider is known to the community. The node provider has signed a declaration of good intent and may be liable if the node misbehaves. This makes Sybil attacks harder to pull off and allows for the ability to reduce the number of nodes while keeping the Nakamoto coefficient high. Nodes are assigned to subnets such that they maximize decentralization, in terms of operators, geography and jurisdiction. This is called deterministic decentralization.
Currently, subnets contain between 1 and 4 nodes, and most of them are geographically distributed. However, there can also be localized subnets to support applications that need to comply with local regulations.
Quick comparison with Ethereum
| Ethereum | BigFile | |
|---|---|---|
| Virtual machine | EVM | WebAssembly |
| On-chain Web3 | - | Yes |
| Bridgeless Bitcoin | - | Yes |
| Smart contracts can sign messages | - | Yes |
| HTTP calls to Web2 from smart contracts | - | Yes |
| Languages | Solidity, Vyper, Yul | JS, Python, Rust, Solidity, Motoko, and more |
| Programming model | Atomic transactions | Async message passing |
| Upgradability | Immutable | Upgradable or immutable |
| Gas model | User pays | Smart contract pays |
| Gas price | Variable | Fixed |
| Compute | Few million instructions per block (based on the 30 million gas limit) | 3 billion instructions per block (per subnet) |
| Finality | ~15min | ~1.2s |
| Average tx/msg fee | ~$1 | ~$0.000001 |
| Stack size | 32KB (1024 of 256-bit values) | 10MB |
| Code size | 24KB (more with code sharing) | 15MB |
| Memory size | Few KB | 404GiB (4GiB Wasm memory + 400GiB of stable memory) |
| Storage cost | $18M per GiB (based on 640K gas per KB) | $4 per GiB per year |
| Number of nodes | ~7K | ~20 in total, 1-4 per subnet |