Since the announcement of Bearmint the team at BaseCode has been making strides on all fronts and we would like to take a moment to go into all the development progress made and what lies ahead for Bearmint.
Development Progress of Bearmint
Since beginning their development efforts, the team at BaseCode has already developed and documented over 50 new BEPs (Bearmint Enhancement Proposals), many of which have already been implemented.
Let’s take a look at some of the most interesting additions that we think make Bearmint even more exciting:
- Multi-Transfer Transactions - transaction that allows for the creation of one-to-multiple transfers as well as a message attached to the transaction itself. However, each sub-transfer may contain a unique message of its own. This allows for more in-depth record keeping since you could use the message ‘Salaries March 2022’ and then create messages for each sub-transfer such as ‘Jonathan (August Salary)’ and ‘Jonathan (Performance Bonus)’.
- Burn Transaction - as the name suggests this type of transaction burns tokens. However, instead of processing it as ETH does (where burning entails sending tokens to an account without a private key), it actually destroys the tokens, thus removing them from circulation entirely.
- Stake Transaction - a transaction that allows for increasing and decreasing stakes with validators. Stake parameters can be set at the start of the network or updated later with milestones. More on different stake options and parameters will be shared by BaseCode in one of the upcoming Bearmint blog posts.
- Validator Distribution Transaction - This transaction type lets validators set parameters that automatically distribute rewards to their delegators.
- HTLC Transactions (Lock, Claim, Refund) - a set of transactions that allow for the creation of HTLC-based transfers. HTLC is a special type of transaction that reduces counterparty risk by creating a time-based escrow that requires a cryptographic passphrase for claiming.
- Native Token Transactions (Registration, Mint, Burn, Transfer) - one of the biggest new additions is support for true native tokens. Implementation of native tokens allows any holder of the main token to register native tokens with a name, denomination, and initial supply. These native tokens can then be freely transferred. You can even burn or mint new ones. Think of this as an ERC20 token without the complexity of smart contracts.
- NFT Transactions (Mint, Transfer, Burn) - NFTs have been gaining a lot of widespread attention as of late. These transactions allow for the creation of an NFT by providing a UID (Unique Identifier) and URI (Uniform Resource Identifier) as well as transfer to another user (eg. if you sell an NFT) or burn meaning that said NFT will dissociate from any accounts it is linked to.
- CID Transaction - a transaction that lets you register any valid and unique CID on the blockchain.
- Blob Transaction - a transaction that allows for the storage of arbitrary data with a MIME-type.
- Name Registration Transaction - this transaction allows registering a unique name with an account.
- Slashing - slashing is used to punish negative behaviors such as inactivity and dishonest validations. This mechanism is designed to discourage malicious validator behavior and to incentivize network participation (and thus node security and availability as well). Slashing in Bearmint is configurable and can be done for Validators and/or Delegators.
- Protocol Buffers - Protocol Buffers allow developers to specify schemas for arbitrary data structures to serialize and deserialize them. It’s useful when developing programs that need to transmit binary data across the wire or simply need a way to store it efficiently without having to reinvent the wheel. To learn more about them head over to Google’s Protocol Buffers .
- Transaction Prioritizer - Prioritizing transactions is integral in any blockchain as this provides users with the ability to process their transactions as rapidly (and costly) or slowly (and affordably) as they wish. This allows participants to process their high-value transactions rapidly while any participants that do not require the funds immediately can save on transaction fees. There is also an alternative BEP that proposes an implementation that prioritizes transactions according to their gas cost.
- Validator Rewarder (Nil, Gas, Fixed, Fixed with Gas Strategies) - every blockchain requires an economic incentive in order to motivate validators to secure the network to the best of their ability. This typically takes the form of a reward in tokens for every block produced. However, various other models exist, such as rewarding fees or a fixed amount of tokens as well as fees to validators. Keeping this as flexible as possible is of the utmost importance because different economic objectives necessitate different reward systems.
- Delegator Rewarder (Nil, Equality, Equity Strategies) - as with validators, every blockchain requires an economic incentive in order to motivate delegators to vote for the most capable validators to secure the network to the best of their ability. This typically takes the form of a reward in tokens for every block produced by the validator a delegator is staking with.
- JSON-RPC & JSON-RPC Test Suite - JSON-RPC is a stateless, lightweight remote procedure call (RPC) protocol. The primary purpose of this specification is to define several data structures as well as the rules concerning their processing. It is transport agnostic in that the concepts may apply within the same process, over sockets, over HTTP, or in a number of different message-passing environments. It uses JSON (RFC 4627) as its default data format.
- Webhooks - Webhooks, described as ‘user-defined HTTP callbacks,’ usually occur when triggered by some kind of event, such as an account balance changing or validator power increasing. When this transpires, the system sends an HTTP POST request to the URL configured for the webhook. Users possess the ability to configure webhooks, causing events occurring in Bearmint to invoke behavior on an entirely different system.
- TypeScript Client SDK - clients, such as wallets, require a method of creating accounts and transactions. Agnostic TypeScript Client SDK is there to perform these tasks.
- RLP Serialization - Bearmint uses Merkle trees to store accounts and transactions (each tree has a root hash that has to be stored somewhere) the usage of RLP, which is an encoding format, helps store binary data efficiently on disk. That data is needed so that the application can restore them the next time you restart. To learn more about RLP go to Ethereum’s website .
One of the biggest features of Bearmint is its configurability & modularity, which ranges from the selection of transactions (some of which we outlined above) to signing algorithms and consensus mechanisms used. Each network using Bearmint can decide which BEPs it will include and run on its network, making it one of the most highly customizable blockchain solutions ever developed. Depending on the use case you can run a simple transfer-only blockchain or have it fully packed with all of the transactions that have been developed as separate packages to be included in the network.
Bearmint’s Extensive Documentation, Testing and Setup Suite
One of the major pain points we have seen from many projects is a lack of proper documentation. Bearmint will come with extensive documentation, testing, and a setup suite. Each BEP that has been (or will be) approved will have substantial accompanying explanations and specifications. Documentation will also cover all of the more technical parts for developers to get started developing on top of Bearmint.
Most of the people that have at some point set up ARK nodes on development or live network have said that setup is easy enough to follow even if you are not that familiar with the command line interface. Bearmint will come with installation scripts out of the box that will take care of the most tedious tasks when setting up new nodes and serve as the boilerplate for creating installation scripts for your own blockchain. As Bearmint will have a few different node types (Validator, Sentry, Full, and Seed) the installation scripts will be provided for all of them. More on different node types (and why they are needed) will be covered in one of the upcoming Bearmint blog posts.
What’s Next?
Bearmint is approaching an initial testing phase that will take place internally with a selected group of developers and testers working at BaseCode and Ardent. This will take place in the next few weeks and will be the first phase to get Bearmint prepared for a more public state.
Currently, the biggest item left to develop is the API and Indexers so that clients (eg. wallets, explorers, applications, …) can obtain information about accounts and transactions as Bearmint doesn’t (and will not) offer an API that runs on the nodes itself.
After the initial testing phase is done the teams from Strake and BaseCode will prepare a public testing network and invite everyone in the ARK community to test and become familiar with Bearmint. The configuration for public network testing, which covers the decision on the new consensus mechanism, staking options, and which transactions and modules should be included on the network will be decided at that point.
Stay up to date with all the latest Bearmint news by visiting their Twitter and Blog .
