The Rise of the Blockchain Architect: Defining a Crucial Role in Web3 | Slava Serebrianniy

Hello everyone and thanks for joining. In the next 20 minutes we will try to establish two things. First we will try to understand who is the blockchain architect and next we will try to kind of understand what are the questions and considerations that should be taken by the blockchain architect when designing a blockchain based product. So my name is Slava Slava Serebryani. I'm leading the developer relations efforts for Fireblocks.

Before actually uh um running in this role I was leading the solutions engineering team at Fireblocks. I've been working with our clients on integrating Fireblocks into their systems helping them to design their product understand their needs and uh um that's pretty much it. Uh a few words about Fireblocks before we actually deep dive into the topic. So Fireblocks is a digital asset management platform. Uh at the core service we uh provide secure wallet infrastructure and we design that in a multi-layer security approach.

At the basis you can see that we are using a secure hardware elements. Basically we are using a um secure enclave technology trusted execution environment technology such as SGX provided by Intel and also AWS Nitro Enclaves. On top of that we have the MPC-CMP algorithm that basically allows you to split your private key into N parts and store every shard on a different physical location and basically by that eliminating the single point of failure of your private key existing as a whole in a single place. And on the top layer we have the transaction authorization policy engine that basically allows our clients to uh the define set of rules and actually segregate duties across their stakeholders in their platform and basically to govern the flow of the assets out of their wallets. Okay, so what are the blockchain product concerns?

Uh what you be should be thinking about when you define or when you're designing a blockchain product? At the top we have the traditional tech stack question and we are not going to focus on that, but basically this is um questions around which cloud providers you should use, which programming languages we should use, how would do my uh networking architecture would look like, so and so forth. Then we are deep diving into the choosing the relevant blockchain uh layer or choosing the network for our product. Which blockchain should we use? Uh by nature blockchain products are financial products.

So, uh you should be thinking about trust, security, risk management, custody model and architecture, uh wallet structure, wallet operation, smart contract uh operations and management and architecture. Uh there are so many uh more aspects that should be taken into consideration here, uh but we try to close this list in that way. So, who is the person that actually makes all of these decisions? Who is the person who actually takes those uh questions and uh uh takes those into conside- takes those considerations into account? Uh in your organization it might be the CTO, uh solution architect, technical product manager, or maybe a group of people that actually work together on defining that.

But with Fireblocks uh try to define this person as the blockchain architect. And the definition that we kind of trying to establish here is the following. So, as any architect, the blockchain architect basically is responsible for the high-level design, strategic planning, and take decisions of the blockchain-based product. As part of his job, blockchain architect takes into account business needs, product requirements, compliance and regulatory guidelines, security concerns and software requirements, and basically produces the best possible solution that addresses all the business needs. Okay, great.

We defined the blockchain architect role. Let's try to define the considerations or ask the questions that should be asked when designing such product. So, we decided to view that in a kind of multi-layer approach or a stack, where at the bottom you have the blockchain layer, and this layer is all about the questions that you should ask yourself when you designing and when you are trying to choose the relevant blockchain. On top of that, we have the core services, which is basically the layer that is in charge of all the core services or the core products that you need in order to run your uh blockchain-based product, such as wallet, trust and model security assessment, et cetera. And on the upper level layer, we can see the connectivity and interoperability, basically integrations that you need to have in order to kind of complete all of the required use cases in your product.

So, let's get started and actually deep dive into the first layer, which is the blockchain layer. But just before For I would like to Sorry for that. I would like to mention that um um we only have 20 minutes, so it's really hard to cover all of these aspects, right? So, we'll go quite high level. So, blockchain layer, what do you need to ask yourself when you're choosing a blockchain?

There are so many uh blockchains, right? I put some logos here on the slide, but there are actually so many more that I missed. And uh how do you know which blockchain works the best for your product? So, we kind of uh built a list uh of questions that you should you ask your that the blockchain architecture that asks himself uh when he's uh going for this decision. The first one is quite easy.

If it's a specific-oriented blockchain product, let's say Bitcoin ETF product, it's easy, right? He will probably go with the Bitcoin blockchain. And uh if it's not the case, uh it it's it's getting uh uh much more complex than that. And then you are going into the aspects of private or public blockchains. Now, I know that some of you don't think that private blockchains are blockchains, but in reality, they are.

And it dep- it really depends on the use case and um for example, I can give an example of a traditional financial institution that builds his product on the blockchain, they will probably go first with the um private blockchain just because of legal and uh regulation concerns that they might have. On the other hand, if you're designing a product that should be accessed by anyone in any place in the world, you probably will go with the, of course, public blockchain. Uh it's not only about public or private, it's also about centralization and decentralization. So, if we are going back to the example of the um uh uh, financial institution, basically, by their product will be more centralized because they will probably own the blockchain, the private blockchain. Unlike the DEX or the DApp that you will build, and it will be on a fully decentralized blockchain, public blockchain.

And also there we have kind of a range of decentralization, right? There are blockchains with 10, 20, 30 nodes or validators, and there are blockchains with hundreds and thousands of validators. Ecosystem, uh, ecosystem is really important. Most of the products or most of the companies actually decide which ecosystem they will choose before they actually choosing the network or the blockchain. And it's driven mostly by three questions.

If you are looking for a specific, uh, feature that is, uh, provided by a specific ecosystem, you are locked to that ecosystem, right? If you are uh, if your product is relying on other projects that on a specific ecosystem, you are also locked to that ecosystem. And, uh, the third one is actually the developer community uh, around that specific network, right? So, if you are looking for a strong developer community, uh, that actually innovates, improves, and builds all the tools that are needed in order to access your product, uh, this is something that you might want to consider as well. Scale and speed requirements.

So, when blockchains blockchains started, right? They were producing blocks like in in in minutes. And that was fine because that was the standard, but today we have really fast blockchains, right? Uh, that produce or vali- validate transactions within seconds or even sub-second. And also handling high gas prices or fees.

Some use cases are more sensitive to that, some use cases are not, but you need to make sure that your business model actually works, uh, with, uh, with that kind of, uh, fee structure, nice, um, fee structure in, uh, in your use case. Sorry for that. Just a second. Good to go? Great.

And security analysis, of course, you need to understand the security structure of that network. You don't want to expose yourself or your clients to unnecessary security incidents because you haven't explored that before you chose that specific blockchain. So, if you answered all of these questions and got into some um answer, you probably did a great job or reasonably be great job. But, if you want that decision to be even better, you need to make sure that you answer also these. So, blockchains are breeding living products.

Unlike your cloud provider, they are um upgrading. They have hard forks. They have uh um road maps that you need to be familiar with. Right? So, don't forget about that cuz it causes a lot of um maintenance burden that you might want to think about before designing your solution.

And, of course, regulation. Regulation is very important. Regulation drives a lot of decisions that the blockchain architect actually does. Uh we will talk about it a bit more in the in the next slide. Uh hype and company growth.

So, you might want to design your product on a specific hype blockchain. The hype will be over until by the by the time that you will release your product. So, you won't be irrelevant, right? Make sure that you are not choosing blockchains because they are hyped. And then, if you decided to go with a specific blockchain, right?

And in the future would like to expand or to migrate, make sure that you design your system in a way that helps you to migrate or expand in a very easy manner instead of reconstruction or re-architecture in your entire infrastructure. Great. So, we discussed the blockchain layer. Let's deep dive a bit into the core services. This is an example of quite a simple architecture of a blockchain-based product.

Most of our clients would say that it is it is very simple. Actually, it gets much more complex than that. But, the core layer is all about building a trust and security model around your around your product. So, custodial custody model is something crucial that you need to be thinking of when deciding how to design your product. Custody models is driven by two things, mostly by two things.

Regulation, as I mentioned before, and end-user requirements. So, if your end-user actually require you to hold their keys, and they don't want any responsibility for that, you are becoming a custodian. And that means a lot in terms of regulation, you might need to have all the licensing and whatever is required for that. On the other hand, if they want to have the ownership of their keys, you probably need to go with a non-custodial wallet solution. Wallet structure, there are mainly two wallet structures out there.

Omnibus versus segregated. Omnibus works better for products that are retail-facing products. Basically, it's like the the regular bank account model that you can think of. You Your end-user deposit his funds into his account. Those Those funds are swept into an omnibus wallet.

And that's basically it. Segregated wallet structure is more for institutional-facing clients. So, if you're if you're serving institutions, probably you would like to go with the segregated wallet structure and there is a huge difference between those in terms of operation and a financial aspects of the system. Wallet trust model so security is everything about security. If you don't have security in your wallet infrastructure, you can close the shop and go home.

So you need to make sure that you have the highest level of security in your wallet. If you are doing that in-house or going to a third-party vendor, you need to make sure that you take things like cryptography and zero trust architecture into consideration thinking about MPC, multi-sig, account abstraction wallets and all of these kind of considerations out there. Blockchain data access. If you want to access data on the blockchain, this is hard. Every blockchain has its own interface for accessing data and then if you want to manage nodes, you need to make sure that you have disaster recovery, high availability procedures in place.

And again, if you are taking a third-party vendor here into consideration, you need to make sure that you are going for the entire counterparty risk assessment as as they discussed before. Smart contract trust model. Basically, if you are developing a product that is built upon or on top of smart contracts, you need to make sure that you are going through all the relevant audits. And internal operation security making sure that you have all the access policies or internal access policies in place. Great.

So we covered blockchain layer, we covered the core services. Let's take a talk a bit about the connectivity layer. Connectivity connectivity layer is all about beyond the keys and signing. What you actually need beyond a wallet. So we have the transaction approval flow integrations.

If you want to make sure that you have the relevant approval processes and regulation uh compliance processes in your place such as AML and KYT, uh you need to you need to make sure that you define those when designing your product. Transaction status and balance updates. So, this is actually similar to uh getting access to on-chain data, right? You want to make sure that all the balances in your system are valid and there are uh uh there is no discrepancy between the balances that you run into your system or transaction transaction statuses uh um and they are the same as in the blockchain itself. Fee estimation.

So, basically, we want to know how we are going how much we are going to pay for a specific transaction. So, we need to have the um um we need to have all the fee estimation processes in place to make sure that we understand how we build that estimate and how we estimate these fees in a dis- in addition to recovering stuck transactions such as uh CPFP processes, uh RBF, and boosting your transactions in general. Fiat and exchange transfers. So, if you need an off or on ramp fiat into your product, make sure that you understand that you need integrations to fiat providers. And smart contract management.

The entire full life life cycle of smart contract management such as deployment, maintaining, upgrading, and basically performing different contract operations. Liquidity network integrations. So, if you are looking to get access to liquidity, uh market makers, OTCs, you need to make sure that you're establishing all of these uh integrations with them. So, probably you noticed all of these uh things that we just discussed in the connectivity layer is about integrations. So, you are going to manage a lot of vendors and a lot of integrations to different third-party providers.

So, you need to make sure that you understand that it's going to be a lot of effort in terms of development and maintenance. We came up with this formula, which is basically if you're running a retail service solution and you are operating on three blockchains, you will probably have something around more than 20 integrations to build and maintain. Okay, great. So, we cover all of these layers. Thank you for listening.

I would like to invite you to get a free sandbox environment in Fireblocks by browsing to fireblocks.com. You can also check out our developer portal, publicly available documentation at developers.fireblocks.com.

And also, we are going to host a side event here at Denver tomorrow. All the details can be found in the side event website at Denver side event website. Thank you so much.