Who are ArcBlock, and why do they love the BEAM?
ArcBlock is on a mission to take the complexity out of blockchain and fast track its adoption into everyday life. To do this, they've developed an all-inclusive blockchain development platform
that gives developers everything they need to build, run and deploy decentralized applications (dApps) easily. At the heart of their platform is the BEAM VM. They're such big believers and supporters in the Erlang Ecosystem that they joined the Erlang Ecosystem foundation as a founding sponsor. In this guest blog Tyr Chen, VP of Engineering at ArcBlock, will discuss why they love the BEAM VM and the benefits of using it as a cornerstone for anyone wanting to build dApps.
An introduction to the BEAM and blockchain
Erlang is one of the best programming languages for building highly available, fault tolerant, and scalable soft real-time systems. The BEAM is the virtual machine - and the unsung hero from our viewpoint. The benefits of the BEAM apply to other languages run on the VM, including Elixir. No matter what high-level programming language people are using, it all comes down to the BEAM. It is this essential piece of technology that helps achieve the all-important nine-nines of availability.
Today, the BEAM powers more than half of the world's internet routers and we don't think you have to look much further than that for validation. Below are some of the benefits of the BEAM that make it perfect for building blockchains.
Network Consensus
Our decision to leverage the BEAM as a critical component for building decentralized applications (dApss) was an easy one. To start, blockchain and decentralized applications, need to achieve a consistent state across all the nodes in the network. We accomplish this by using a state replica engine (also known as a consensus engine). Consensus is important as this mechanism ensures that the information is added to a blockchain ledger is valid. To achieve consensus, the nodes on the network need to agree on the information, and once consensus happens, the data can be added to the ledger. There are multiple engines available, including our current platform choice, Tendermint, to support the state replica engine.
The BEAM + dApps
Apart from the consensus engine, the BEAM is the perfect solution to satisfy several other critical requirements for decentralized applications. For decentralized applications to work in our development framework, we need to have an embedded database to store the application state and an index database for the blockchain data. While this is happening, we also need the blockchain node(s) to have the ability to listen to peers on the network and "vote" for the next block of data. For these requirements, the system needs to be continuously responsive and available.
Now, it's also important to note that in addition to being continually responsive, we also need to account for CPU-tasks. In particular, our blockchain platform and services cannot stop working when the system encounters CPU-intensive tasks. If the system becomes unresponsive, a potentially catastrophic error could occur.
Hot Code Reloading
Besides BEAM's Scheduler, another feature we love is hot code reloading. It lets you do virtually anything on the fly without ever needing to take the BEAM down. For example, our blockchain application platform ships with lots of different smart contracts that developers can use to make their decentralized applications feature-rich. However, with blockchain, you have a distributed network and need to ensure that every node behaves the same.
In most cases, developers have to update and reboot their nodes to get the latest software enabled, which causes potential issues and unnecessary downtime. With ArcBlock, we utilize the hot code reloading feature of BEAM to let the nodes enable/disable smart contracts on the fly across the entire network. This is simply done by sending a transaction that tells the system it should upgrade the software at a specific time. When that happens, ArcBlock will tell the BEAM to install the new code, and then every node in the network will have the latest features ready to go.
Speed is Relative
The BEAM uses the "actor model" to simulate the real world, and everything is immutable. Because of this, there is no need to lock the state and prevent the race condition. Of course, everything comes with a cost. The simplicity and beauty of immutability in the BEAM could lead things to run slower. To mitigate potential slowness, ArcBlock leverages Rust to help the CPU on intensive tasks such as the Merkle-Patricia tree for states. And once again, the BEAM demonstrates its value by providing an easy way to communicate with the outside world using Rust to boost the performance to another level.
Garbage Collecting
Don't let the name fool you. Garbage collecting is critical. Erlang uses dynamic memory with a tracing garbage collecting. Each process has its own stack and heap, which is allocated in the same memory block and can grow towards each other. When the stack and the heap meet, the garbage collector is triggered, and memory will be reclaimed.
While this explanation is a bit technical, the process for garbage collecting in BEAM is done at a process level, ensuring that there will never be a "stop-the-world-and-let-me-clean-up-my-trash" type of garbage collection. Instead, it ensures that processes will continue without any type of interruption.
OTP
Last but not least, Erlang provides a development suite called OTP that gives developers an easy way to use well established best practices in the BEAM world. For any enterprise or blockchain application platform, building around industry standards is a must, and OTP makes it easy to write code that utilizes all the goodness available to developers in BEAM.
Fault Tolerance
There is a reason we saved this for last. This is by far the feature ArcBlock rely upon the most on the BEAM, it is what elevates the BEAM over many competitor technologies when it comes to blockchain. Although tens of thousands of transactions are happening simultaneously; any error that occurs in certain parts of the system won't impact the entire node. The errors will be self-healing, enabling the node to resist bad behaviour or specific attacks. For anyone who is delivering a service to users, or supports a production application, this is a critical feature. By including fault tolerance by default, we can ensure that anyone running on the ArcBlock platform can remain online and available.
We believe that the BEAM, while designed many years ago, was intended for blockchain. It gives developers and blockchain platforms like ArcBlock, all the necessary features, and capabilities to run a highly concurrent, fault tolerant system that makes developers' lives easier.
Keep calm and BEAM on.
Learn more
Tyr Chen, VP of Engineering at ArcBlock is the guest host of our webinar on Wednesday, November 27. Register to take part, and even if you can’t make it on the day, you’ll be the first to get a recording of the webinar once it is completed.
Top comments (0)