A blockchain architect is responsible for high-level design, strategic planning, and tech decisions for blockchain-based products.
In the rapidly evolving landscape of Web3 and blockchain technology, a new pivotal role is emerging: The blockchain architect. The blockchain architect is not just a sub-type of the software architect. The blockchain system architecture requires the blockchain architect to make decisions involving security, regulation, and financial considerations, in addition to standard software architecture concerns that do not exist in other domains in the same way. While many people are actively doing this job, few of them have a name for it, which is why we are here to bring some well-deserved awareness to blockchain architects.
What is a Blockchain Architect?
A blockchain architect is not someone building blockchains but rather someone building a product that leverages the blockchain as a core building block. There are many systems that blockchain architects build – digital assets, financial operations systems (exchanges, market makers, OTCs, order execution, settlements systems, etc.), custody solutions (crypto/NFT wallets, Neo Banks, etc.), B2C crypto investing tools (crypto only, or crypto and stock), Web3 and brand programs (loyalty programs, etc.). While these systems are extremely different in their domain, they have a common ground of blockchain-related operations and considerations, which are the focus of the blockchain architect.
As more companies embrace blockchain technology as part of their tech stack, they face these new complexities, making the role of a blockchain architect increasingly sought after across the global tech industry.
Blockchain Architecture 101
When defining the architecture of a blockchain-based system, consider the following:
- Underlying blockchain(s)
- Trust, security, and risk architecture
- Custody architecture and wallet structure
- Incoming and outgoing transaction processes
- Blockchain operation financing and liquidity access
- Smart contract architecture and management
- Blockchain data access, indexing, and monitoring
While each of these domains is a complete and complex world of its own, there is a strong connection and influence between the decisions made across this system, which pushes us towards the same person (or group of people) having to account for all of these decisions as a cohesive architecture.
Choosing a Blockchain
Choosing a blockchain is definitely one of the most important decisions in blockchain architecture and has a very strong impact on the other architectural concerns we will discuss.
For example, choosing to use Bitcoin as an underlying blockchain would mean you are not using account abstraction wallets or any other smart contracts or have easy access to stablecoins. However, you will benefit from a strong network decentralization and anti-censorship framework and access to strong analytics and AML tools. You will have direct access to a very important digital asset – BTC – even if it means having volatile transaction fees and long finality times. A different blockchain decision will drive entirely different tradeoffs regarding functional and non-functional requirements and capabilities.
The parameters of choosing a blockchain include access to specific assets and liquidity, access to ecosystems of users and services, protocols, block speed and finality time, gas/fee costs of operation, centralization and decentralization, private or public access, ecosystem connectivity, risk posture, consensus mechanism, future outlook, security model, social layer, roadmap, cryptography and more.
While some products are built on a single blockchain, many would require multiple blockchains as part of their operation, whether because they need to support multiple digital assets, desire to offer the system in multiple separate ecosystems, or access to segregated liquidity. Companies that start with a single blockchain infrastructure might support more blockchains with time.
Trust, Security, and Risk Architecture
While every software system has a trust model, the blockchain ecosystem has unique identifiers that push the trust, security, and risk parameters to the top of the consideration list. Most notably, all systems on the blockchain are financial in nature as they deal with assets for operation or functionality. Additionally, the blockchain is a unique infrastructure with a strong risk footprint. The private key for accounts and all other wallet operations are top concerns, and the smart contracts layer comes with many potential issues related to trust and security.
With this in mind, building a system that accounts for internal and external threats is a very complex task that requires a deep understanding of the underlying risk and security model of all the systems mentioned above.
Multiple parameters impact the blockchain risk and security model. They are dramatically different between blockchains, including consensus mechanisms, decentralization of all layers of operating infrastructure, cryptographic implementation decisions, and the tendency for changes in core building blocks. Many blockchains have a very delicate alignment and sometimes misalignment between the incentives of different infrastructure participants. This creates long-term tensions and power shifts, impacting the risk factor over time.
Wallet providers have stepped up to address many security and risk concerns their clients face. Understanding the desired security architecture of wallets is one of the most important parts of assessing the solution’s entire risk profile. The simple separation is between the high-level architecture of a single-signer, smart contract multisig, and MPC wallets. However, dive just a little deeper, the risk model of MPC wallets alone will start breaking down into more specific details – does the client hold a share of the private key, which MPC algorithm is used (if it’s actually MPC of SSS), which secure enclave is used, and what runs in the enclave or outside of it, and much more. Such consideration exists within each solution, and it’s up to the blockchain architect to digest these into a decision.
Smart contracts have been the target of billions of dollars in exploits over the last few years after being audited by top security researchers. Smart contracts have a wide attack surface as they are on-chain, visible to everyone, and accessible by anyone. Once they reach a level of complexity, even a small issue can amount to a complete loss. In addition, smart contracts are mostly written in a new programming language with new paradigms and trust assumptions. The ecosystem around the smart contract also impacts the smart contract itself in a meaningful way, and adjacent technologies like MEV and Flashh loans can impact the risk profile of the contract. In addition to the security risk, one has to understand the financial system risk and vulnerability to financial attacks.
Custody Architecture and Wallets Structure
All blockchain-based systems require at least one wallet to operate; however, most blockchain systems require much more than one wallet. Wallets are a layer of the solution that requires an architecture of its own for operations and end-user services.
The first layer of wallet architecture is the operational level. Before even thinking about the users, a blockchain architect will likely need to consider how to build out the operations for treasury, smart contracts, and other aspects of the solution that reside on the blockchain. In many situations, the operation will require more than a single wallet for security and risk, access management, and other reasons. The blockchain architect would need to define the architecture of this system while adhering to the custody regulations for different digital assets involved (financial and non-financial).
The second layer of the wallet architecture is the user management. If users are required to have wallets, the blockchain architect must understand how these wallets operate and their custody model. Multiple paradigms for these architectures have been built under the wallet-as-a-service domain, each with its own custody, security, compliance, and operation model.
Another important layer when designing and developing a wallet solution involves assessing the required wallet type and addressing the daily operational demands. Wallet types, such as cold or hot wallets, depend on factors like regulations and geographical locations. Some organizations may require a cold wallet, while others might find a hot/warm wallet or a combination of both suitable.
Regulations in certain jurisdictions mandate custodians to manage cold and hot wallets, with a significant portion of assets stored in the cold wallet with daily reconciliation procedures. Additionally, the scale of wallet operations plays a vital role. Considerations include whether the system needs a fully automated setup for high transaction volumes or if a few manual transactions by the operations/treasury team would suffice. The wallet(s) must also handle high transaction volumes based on throughput and the underlying network architecture.
In essence, a blockchain architect must comprehend the production system’s complete requirements, adhere to legal obligations in the operating jurisdiction, and factor in the scale and required throughput. This ensures the design of a well-suited wallet structure tailored to the system’s needs.
Incoming and Outgoing Transaction Processes
One of the biggest disconnects between the blockchain layer and its usage is the context of a blockchain transaction. While all actions are the same at the blockchain layer – they are handled differently by off-chain systems monitoring and interacting with the blockchain.
For outgoing transactions – although the signature (and broadcasting) is the start of the process on the blockchain, it is actually the end of all the internal processes around the transaction for the initiating party. Before a transaction is signed, it will likely go through an approval process that might be long and complicated and include both automated and manual processes. The transaction might be screened for compliance, internal procedures, security analysis, internal system record keeping, and much more.
Incoming transactions also require processes for monitoring, updating internal systems of record, and initiating subsequent flows.
Blockchain Operation Financing and Liquidity Access
As all public blockchain operations come with a cost, the system operator must manage the native assets used for the system operation and ensure that the relevant wallets/systems can always perform their tasks while paying for the required on-chain services. This may be partially solved in some ecosystems with gas/fee delegation, but in others, it’s a core requirement of the architecture. In addition, a blockchain business will often require certain levels of liquidity beyond the native token to operate (e.g., protocol utility tokens like Chainlink’s LINK), especially in the crypto trading business, which is all about access to liquidity of digital currencies.
Smart Contract Architecture and Management
A strong blockchain architect always considers what aspects of a system need to be on-chain and what can be off-chain. On-chain elements of a solution provide transparency and verifiability, which are often the drivers for the solution to be deployed to a blockchain. However, attempting to put everything on-chain is often a mistake that increases project complexity, flexibility, and cost.
Software development for blockchains is dramatically more expensive than traditional software development due primarily to the increased threat model of running code on a public blockchain. To counteract these risks, smart contract code must be thoroughly tested for correctness and that any access management is correctly implemented. Furthermore, smart contracts often need to be audited, which is expensive and time consuming. Change and release management for smart contracts is wildly different from traditional software deployments.
Striking the right balance between on-chain and off-chain elements is a matter of understanding stakeholders’ requirements, especially as it relates to code complexity, accessibility of data, and the velocity of changes that are likely to be made. For example, rather than trying to discover the price on-chain for a swap, it may be sufficient to have one party discover the price off-chain (e.g., via API) and update a price on the smart contract so that other participants can use it. Of course, any aspect of a solution completed off-chain will have different trust assumptions, which must also be considered.
A key benefit of public blockchains is the emergence of open standards which foster interoperability. As part of any smart contract solution, a blockchain architect should first look at how they can leverage open standards (ERC20, ERC1155, and ERC721), as this will improve the system’s ability to operate with others (e.g., to list a token on Open Sea or Blur automatically). Blockchain architects must also decide conceptually whether they seek to enrich or compose these standards into protocols. Enriching standards often means inheriting the standard and adding functionality, whereas composing means keeping standard contracts “as is” and managing them with separate helper/manager contracts. Both approaches have their pros and cons, which should be explored. As open standards define some of the smart contract architecture, it’s important to have a smart design for the other components to allow future expansion and upgradability as the products and surrounding ecosystem evolve.
Blockchains (and DeFi in particular) have been designed to enable “permissionless” access, where all users are treated equally and centralized control is frowned upon. Permissionless access is principal and should always be considered by a blockchain architect as it often simplifies smart contract architecture. However, some level of access control is often required (e.g., to control mints/burns or contract upgrades) and should always be carefully considered as it also creates new threat models for accounts with privileged access. The owner or operator of the smart contract should develop an entire system around operating these capabilities.
Blockchain Data Access, Indexing, and Monitoring
Reading the blockchain is one of the most data-intensive operations, especially with faster blockchains that have become popular over the last few years. While simple data monitoring operations such as incoming transactions are supported quite easily by the blockchain nodes, supporting more intensive data retrieval and indexing operations across multiple chains is becoming increasingly more complex.
Multiple systems have been developed to solve the data challenges in the domain, each focusing on a single core responsibility, such as data retrieval, indexing, analysis, anomaly detection, or dashboarding.
Engineers accustomed to working with traditional databases might find it surprising that a transaction included in a recent block can still be reversed. Blockchain reorganizations and forking happen and need to be modeled properly by off-chain monitoring and indexing services.
Once deployed, smart contracts will be executed in a decentralized manner, which means a blockchain architect should be considering how they will monitor their solution. A number of large-scale blockchain hacks took place unbeknownst to the protocol operators until months after the attack. These hacks could have been mitigated with appropriate monitoring. Traditional monitoring solutions are generally incompatible with blockchain events, so custom tooling is often required. These tools can alert administrators to suspicious behavior like mints and changes in access control, which can help mitigate the impact of any breaches.
How to Become a Blockchain Architect
Becoming a blockchain architect will require you to have a reasonable level of understanding of all blockchain architecture sub-domains. There are still very few formal education programs for this rising field of interest, so most people are learning this role through on-the-job training. The best way to learn blockchain architecture is to build a blockchain-based system. Doing it as an employee or intern of an innovative organization focused on real-world projects is especially useful. It is also important to keep up to date with the evolving blockchain technology landscape as it evolves rapidly, with new solutions constantly becoming available. Fireblocks, for example, provides developers with a free testnet sandbox environment that offers builders across all levels of expertise the opportunity to experiment with building blockchain-based products.
What’s Next?
To delve deeper and learn the distinctive and multifaceted nature of blockchain architecture, we invite you to register for our webinar, “The Rise of the Blockchain Architect.” During the session, we will discuss choosing the right blockchain, designing the wallet structure, identifying the right custody model, trust security and risk architecture, smart contracts architecture and management, blockchain data access and monitoring, and more.
For those attending ETHDenver, Fireblocks will host a half-day workshop on this topic. The workshop also provides a great opportunity for novice and expert blockchain architects to meet, network, and share fresh perspectives, trends, and real-world insights. Register for the workshop here.
