Beam 2021 Week #17 - The BVM
Covering April 19th - April 25th 2021
Download Beam Android Wallet | Beam iOS Wallet | Beam Desktop Wallet
Beam News
Discuss the BVM along with some insights into WASM, and the reasoning behind it being chose for the BVM, and some changes coming to the fee structuring with the upcoming Beam Hardfork.
BVM
From the get go Beam, being a Mimblewimble based chain, allowed for scriptless scripts. A way to emulate script behaviour off-chain, and broadcast the end result to the network. This is what has powered the Beam Atomic Swaps and payment channels, but their usage does not extend far beyond these. To overcome such limitations, one of the upgrades with the upcoming Hardfork is the Beam Virtual Machine (BVM). This will allow for custom logic to be executable on-chain.
So let’s dive in, and take a look at some of the aspects of the BVM that you may not be familiar with!…
Shader
The term Shader comes from 3D graphics. It means a custom program, as opposed to the pre-defined fixed function.
In Beam, a Shader is a program designed to run within the BVM, and implement the custom contract logic.
Shaders have public methods, which can be invoked either directly by a user, or another contract.
Contract Shader
Implements the contract logic
Strict complexity limitations
Can only access its custom variables (not those of other contracts)
Executed by the BVM in an isolated environment, to ensure bugs or malicious behaviour do not affect the blockchain integrity
Constraints and limitations in place, for example max number of signatures to check, max length of variable to store etc.
App Shader
Provides an interface for specific contracts
No strict complexity limitations
Read any blockchain information
No limitations regarding repeatability
In short, contract shaders are for making changes to the blockchain state. Whilst App shaders can query any information, read the state of all deployed contracts, and prompt users to execute transactions.
get zero-knowledge proofs for it, and etc. In addition to gathering the information, they can "ask" the wallet to create transactions that are supposed to invoke the contracts.
Contract
These are managed by the node, and operated by their shader. They are capable of a variety of functions, including:
Save/load its custom variables (access contract state)
Lock/unlock funds
Create and manage assets
Invoke public methods of other contracts
Demand signatures for arbitrary public keys
Together, these will give Beam the capabilities to allow for custom logic, executed on-chain; enabling DApps to be built on Beam for such things as governance, staking, stablecoins, and AMM based Decentralised exchanges.
Read more on the specifications for Beam smart contracts here
Why WASM?
Simple, there are now around 40 high-level programming languages that support WebAssembly, including C and C++, Python, Go, Rust, Java, and PHP. WASM is not a new language, but a portable, pre-compiled, cross-platform binary instruction set for a virtual machine that runs in the browser. Or in Beam’s case, the node. For these reasons, the Beam Virtual Machine will be WASM based.
R&D
Initially Beam network launched with no minimal fee. The fee was optional, and only meant to prioritise transactions. The assumption was that the fee market should arise when the transaction throughput increased to a level where not all transactions can fit into a block, with users competing to prioritise their transactions. Until then miners should accept all transactions, even those without a fee, since they are interested in keeping the network in smooth operation, and the verification complexity of a typical transaction is negligible.
While it was good for typical users, it was obviously vulnerable to "spamming". Attackers could create an arbitrary number of UTXOs for free, which in turn affects the node storage size, traffic, and sync times. This problem persists in many blockchains, but is even more prominent in MW, since one of its advantages is specifically scalability and low sync time, assuming spent UTXOs are pruned over time.
From the first Hardfork we decided to impose a minimal fee, but make it very low. The fee for a typical transaction was 100 groth, which is only 10e-6 Beam. It was intended to protect against "hooligan" attacks only, i.e. those that want to spam the network, but not pay for the attack. For typical users such a fee was absolutely negligible.
Starting from the second Hardfork, Lelantus-MW functionality (shielded pool) was added. A non-negligible fee was then required for both shielded inputs and outputs, since their impact on the system performance is significant.
Starting from the upcoming Hardfork, Beam’s 3rd, the minimal fee for regular (MW) transactions will be dramatically increased. For a typical transaction the minimum will become 100K groth, which is 10e-3 Beam (an increased of 1000x).
The decision came due Beam attracting much more attention recently, and the threat for spamming attacks is more real. With this, the price of such an attack becomes significant, whereas for a typical user the fee is still very low (fraction of a cent according to today's prices).
Together with this we also removed the minimal fee for shielded input, so the fee is for outputs only, and inputs are always free. This fee will be paid by the sender.
Beam Outreach
The BOC platform has seen some wicked updates and improvements, thanks to the community. A big shout out to Groot and Vsnation, that took on the challenge of jazzing up the design, as per the feedback received.
Key Highlights:
Leaderboard reorganised with users' completed task, and entire task completed on the BOC platform
Interactive task page with comments, tags, upvote counts and task status
User profile captures user image, score, bio, task snapshot, settings, coin balance
Improvements on the way:
Revamped landing page with more info and stats
Wallet that holds both $RAYS and $BEAM
User Analytics
Join in the fun with the BOC crew, take home some $RAYS, and help craft the platform for future Beamers!!
Sign up, stay tuned, and see you all next week!