Introduction
Base BigBang seamlessly integrates with Bitcoin, unlocking new possibilities for DeFi, NFT, and other decentralized applications.
BigBang is a smart contract language designed for the Base blockchain, optimized for predictability and security. It allows developers to encode essential business logic on a blockchain.
The design decisions behind BigBang were based on lessons learned from frequent Solidity exploits, resulting in a language specifically designed for security and protection.
This documentation serves as a reference for the functions and keywords available in BigBang that teach you everything you need to know to create robust smart contracts. The number of smart contract languages is increasing every year, making it challenging for beginners to choose a first language. The choice is largely determined by the ecosystem of interest, although some languages apply to more than one platform. Each language has its advantages and disadvantages. This book does not cover all of them. BigBang is a prime choice for those who require the utmost security and transparency.
It is secure by design, with the design process guided by examining common pitfalls, mistakes, and vulnerabilities in smart contract engineering. Countless real-world examples demonstrate how developer failure led to the loss or theft of vast amounts of tokens. The first is the Parity bug, which resulted in the loss of millions of dollars worth of Ethereum. The second is the hacking of The DAO, a Decentralized Autonomous Organization, which caused significant financial damage and led to a contentious hard fork to undo the theft. Two major issues have highlighted the need for improved design of the Ethereum language. These and other mistakes could have been avoided with better language design.
BigBang is interpreted instead of compiled, meaning that the code is executed and recorded on the blockchain exactly as it is written. It is crucial to write clear and easy-to-understand code in BigBang. eliminate the risk of introducing vulnerabilities due to a bug in the compiler. Byte-code is not human-readable, making it difficult to verify the actions of a smart contract. It is crucial to comprehend a contract before signing it, and the same applies to smart contracts.
BigBang offers a transparent experience, ensuring that what you see is precisely what you get. It is a significant aspect. A language is considered decidable if the code enables you to determine with certainty what the program will do. This eliminates issues such as the halting problem. BigBang guarantees that any input will result in program execution ending in a finite number of steps. It also enables complete static analysis of the call graph, providing an accurate picture of the exact cost before execution. BigBang ensures that calls will not run out of gas during execution. In the security deep dive on decidability, we discuss this idea further, including Turing completeness.
BigBang prohibits reentrancy, which occurs when one smart contract calls another that then calls back into the first contract, causing the call to 're-enter' the same logic. This can enable an attacker to initiate multiple token withdrawals before the contract updates its internal balance sheet. To prevent this, BigBang's design considers reentrancy an anti-feature and disallows it at the language level.
Additionally, BigBang protects against overflow and underflows, ensuring the security of the contract. Overflows and underflows occur when a calculation results in a number that is too large or too small to be stored. These events can cause smart contracts to malfunction and may be intentionally triggered by attackers in poorly written contracts. This can result in the contract being frozen or drained of tokens. In BigBang, any kind of overflow or underflow automatically aborts a transaction.
The platform has built-in support for custom tokens. Smart contracts are commonly used to issue custom fungible and non-fungible tokens. The BigBang language includes built-in features for creating custom tokens, eliminating the need for developers to manage internal balance sheets, supply, and token events. Later chapters provide in-depth coverage of creating custom tokens.
On Base, transactions are secured by post-conditions. Postconditions can be attached to transactions to assert the chain state has changed in a certain way once the transaction has been completed, further safeguarding user tokens. For instance, a user calling into a smart contract may attach a postcondition stating that after the call is completed, precisely 500 BASE should have been transferred from one address to another. If the post-condition check fails, the entire transaction is reverted. Since BigBang has built-in support for custom tokens, postconditions can be used to protect any other token in the same manner.
It is important to check all returned responses. Public contract calls must always return a response indicating success or failure. Any contract that calls another contract must properly handle the response. Contracts that do not comply with this requirement are invalid and cannot be deployed on the network. Unlike other languages such as Solidity, low-level calls in Clarity require the return value to be checked. This prevents silent failures, such as a token transfer, if the developer forgets to check the result. In BigBang, it is not possible to ignore errors. However, this can prevent buggy error handling by the developer. The chapters on functions and control flow extensively cover responses and error handling.
BigBang follows the principle of composition over inheritance. BigBang smart contracts do not inherit from one another, unlike in languages such as Solidity. Instead, developers define traits that are implemented by different smart contracts, allowing contracts to conform to different interfaces with greater flexibility. Complex class trees and contracts with implicit inherited behavior are not necessary to worry about.
Last updated