As always, our latest Dev Update is packed with exciting topics, this time including:

  • New textual address format for payments: Bech32 Standard
  • Technical documentation updates:
  • Initial threat model
  • Tools & tutorials to get you started on Chain development
  • Transaction accounting model update
  • Next steps towards Public Testnet

New Textual Address Format for Payments: Bech32 Standard

Previously, Chain used hexadecimal formatting. However, during our iteration & continuous improvement of the flow and interface, we have discovered some problems with this address format, for example:

  • Confusion caused by representing different items at the same time (e.g., different types of addresses, transaction identifiers).
  • Lack of robust error-detection mechanism (e.g., unable to detect cases where someone types or copy-pastes it).
  • The addresses are too long for our default payment addresses that support threshold multi-signatures (briefly described in dev update #2).

To address these issues, we evaluated the options and selected representing payment addresses using the Bech32 standard used in Bitcoin, Lightning Network etc. This representation is compact, simple, visually unambiguous and comes with solid error-detection. For the human-readable address part, we proposed the following prefix conventions:

  • cro: for addresses on the mainnet
  • tcro: for addresses on the public testnet
  • dcro: for addresses in local test executions or on private developer testnets.

For example, this is how an address would like on the mainnet: cro1pe7qg5gshrdl99m9q3ecpzvfr8zuk4h5xxnlp9
(in a local developer test execution, this address would be: dcro1pe7qg5gshrdl99m9q3ecpzvfr8zuk4h5rm547c.)

Technical Documentation Updates

We have updated and extended our technical documentation, with a stylish repolishing thanks to our marketing team:

Some highlights on what’s new in the technical documentation:

  • Initial threat model
  • “Getting started”
  • Transaction Accounting

Initial Threat Model

As outlined in the Chain Technical Whitepaper, security remains our top priority. One of the important stepping stones security foundations, as mentioned in the whitepaper, is threat modelling. It is a systematic approach to identify potential security threats by decomposing and enumerating system components.

In collaboration with the security team, we developed the initial threat model for select core components of Chain. The model is mainly based on the STRIDE framework originally developed at Microsoft. You can read more in the hosted version of the technical documentation:

Getting-Started Tools & Tutorials

To help you get started and stay up to speed on the rapid development of Chain, we have updated the documentation for beginners & developer tools.

In the latest update, we have simplified the initial developer workflow and added the “init everything” command that helps to bootstrap the environment needed for developing Chain. You can read more about it in the latest main README file, as well as in the tutorial on the main technical documentation page.

Transaction Accounting

In Dev Update #2, we mentioned that Chain would be using the UTXO transaction accounting model, which functions well for payment operations.

Considering that certain network operations (e.g., staking) function better in the account-based model, we have decided to support both the UTXO & account-based models in the style of chimeric ledgers, where one could transition between either model using special transaction types. You can read more about the motivation behind this design and how it works in the technical documentation.

Next Steps Towards Public Testnet

As we prepare for the launch of the first version of the Public testnet, we would like to share more information about its implementation and actions taken towards its launch:

  • Chain will run on the current Testnet prototype code;
  • The sample UI web implementation of the Chain wallet backend will be released, so that developers can start working with these on the testnet;
  • Security Bug Bounty programme will be enhanced to include potential Chain vulnerabilities in its scope;
  • We will start engaging third parties for architecture and code security audits;
  • The infrastructure, including various web services, will likely be operated by at this stage, though we are in discussions with several industry partners to host Council Nodes for the next phases of the Public Testnet and beyond;
  • The technical whitepaper will be updated in accordance with some of the details described in the technical documentation.

We plan to iterate on the Public Testnet in several phases to run a more complete (we have several exciting features still in our backlog to implement) and more robust code that will make it easier for third parties to participate in the network operations.