AWS Summit ANZ 2022 - Build, launch, and scale your Web3 startup on AWS (START7)

AWS Summit ANZ 2022 - Build, launch, and scale your Web3 startup on AWS (START7)

Show Video

Welcome. My name is Brendan Myers, and I've been a Solutions Architect at AWS for two years, and a developer for the last 15 years. I've been in and out of the blockchain space for a number of years, and at one point, I had a patent that combined IoT and blockchain technology for the secure delivery of packages. At AWS I'm part of the startups team, and we focus on helping our customers solve the unique challenges that startups face. At the end of this talk, I'll share some links that you can use to get in touch with the startups team, and I encourage you to reach out to us if you're building a Web3 startup, or any startup on AWS, as there are a number of different ways we can help you along your startup journey. In this session, I'll be discussing how

you can build, launch, and scale your Web3 startup on AWS, we will define what Web3 is. We'll cover three common Web3 architectures that customers are using today, we'll look at the unique considerations you should take into account when building a Web3 application. This includes security, monitoring, operating and scaling a Web3 application. What is Web3, if you go and search for a definition of Web3, the top five results would give you seven different answers. And a lot of the time these definitions are based on a view of a specific technology, rather than the view of what the benefit is for your end users. Web3 is most easily described by comparing it to Web 1.0

and Web 2.0. So on Web 1.0, we had the read-only internet, static websites, bus timetables, restaurant menus, blogs. Users would visit a website, they'd read information, but they couldn't interact with it. Web 2.0 - the interactive web. This is what most of us think of when we talk about the Internet today - interacting with websites - leaving comments on a blog, planning a project, using social media. In Web 2.0 data lives within a service and access to that data is governed by the owner of that service. The common pattern in Web 2.0 is for

the custodian of data to provide their own view of that data. That can be via a web application, or an API. In Web3, data is separated from the service and lives on the public blockchain. The public blockchain is a digital ledger that is maintained by users around the world. Anyone can view, verify, and interact with that data. Data is immutable, which means the history of that data cannot be changed after it's written. You may have heard of NFTs or non fungible

tokens, which are blockchain backed records that define the ownership of an asset, whether it be digital art, a piece of land in an online game, or something entirely different. NFTs are a great example of data that can only exist using blockchain technology, because to verify ownership, we need unfettered trustless access to the record of ownership. How do Web3 applications differ from standard web applications? If we take a very, very high level look at the parts of a web application, we have application code, and data, which live on servers operated by a single custodian. Web3 applications can still have traditional web application components, but in addition, they also have their blockchain equivalents. Smart contracts and on-chain data. Anyone can view on-chain data, and anyone can view the code that will be executed when a smart contract is run. The bridge between these two worlds is the blockchain client. A blockchain client

abstracts away some of the complexity of interacting with the blockchain and allows you to instead just interact with the blockchain via an API. There are a number of different ways you can access a blockchain client. You can use Amazon Managed Blockchain, a fully managed service which provides you with your own blockchain client, and eliminates the overhead required to join a public network. You can host and run the client using an AWS compute service, such as Amazon EC2. And finally, you can use a third party service such as Infura, which provides an API as a service to access a blockchain.

So far, I've spoken about the underlying blockchain itself, in general terms "a blockchain", rather than mentioning specific blockchains, blockchain networks, L1s, and so on. Everything here is applicable to almost any underlying blockchain technology you choose. But there may be subtle differences. For example, if you choose to build on the Ethereum network, then how you decide to access a blockchain client may be different than if you choose to build on Fantom. When we interact with a blockchain, it's in one of two ways; we're either reading data from the blockchain, or we're adding data to it. Adding data can include actions such as executing a

smart contract, storing data on chain, or transferring an asset. If we're adding data to a blockchain, that you may have seen referred to as "modifying the state of the blockchain", then we have to pay blockchain fees. These are paid for in the native cryptocurrency of the blockchain you're using, for example, Ether for Ethereum, Sol on Solana, ALGO on Algorand, and so on. For your Web3 application it's important to decide who will pay these fees? Will it be your service, or will the users pay the blockchain fees themselves. With reading data, so items such as checking ownership of an asset, viewing an account balance, or looking up token details, these are free in the sense that you don't incur blockchain fees performing these actions. Next, we'll look at the architectures for applications that use these different interaction patterns. In the read-only architecture, as the name

suggests, we adjust reading data from the blockchain. This pattern is very similar to other web applications you may have seen. Here, we have a simple application with static content stored in Amazon S3, and API served by AWS App Runner, and Amazon CloudFront in front of these for low latency access. We're using Amazon Managed Blockchain to access the blockchain network. But this could also be a client you run yourself on an Amazon EC2 instance. Read-only architecture is used whenever you read data via third party blockchain client. The service

pays architecture is similar to the read-only architecture, we still have our web application built using Amazon CloudFront, AWS App Runner, and Amazon S3, and we still use a blockchain client, such as Amazon Managed Blockchain. The key difference is that we are not just reading data from a blockchain, but also writing data. As I mentioned earlier, there are fees for writing data to the blockchain, and to pay these fees, we need a blockchain wallet that is funded. A wallet is just a pair of cryptographic keys. These keys are used to sign and verify transactions that are submitted to a blockchain network. For example, if I wanted to transfer a

digital asset to somebody else, I would create a transaction with the details of that transfer, I would sign the transaction using the private key from my wallet, and I would submit the signed transaction to the blockchain network. The network would then verify my transaction is valid, that I have the funds to pay for the transaction, and because the transaction is signed with my private key, the network can be certain that I initiated the transaction. This should highlight just how important it is to keep your blockchain wallet, your private keys, secure. As the saying goes, not your keys, not your coins. In the service-pays architecture, we can use AWS key Management Service, or KMS, to manage our blockchain keys and to sign our transactions. KMS uses hardware security modules to secure your keys and your keys are only used inside these devices and can never leave them unencrypted. After KMS has signed our transaction it is then

submitted to the blockchain network via our blockchain client. A customer using this pattern today is MakerX. MakerX have built the History Project which mints, catalogues, and sells verifiably authentic digital artifacts created during the most significant events in history. MakerX had started with earthquakes, and each time a significant earthquake occurs, a record of that earthquake is written to the algorithm blockchain - and this record provides a verifiable and causal link to that earthquake. This is a great example of the service

pays architecture, as these records need to be created as an event occurs, which means the service needs to create these records. At the end of this presentation, I'll share a link to this blog post, Mint and Deploy NFT's to the Ethereum Blockchain, using Amazon Managed Blockchain. This blog will walk you through how to build an NFT minting application, using the service-pays architecture, and contains step by step instructions, code and everything else you need to get started today. Finally, the user- pays architecture. If you're new

to blockchain and Web3, then this pattern may look a little odd at first, but it's fairly simple to understand with an example. Let's say I have a website and that website lists NFT's I own and users can buy my NFTs. I have my static site in S3 behind CloudFront. A user visits my site and

decides to buy one of my NFTs. The user creates and signs a transaction for the purchase of the NFT and they submit that via their own blockchain node. For the user, this happens in their browser with the help of a wallet plugin such as Metamask. The transaction is gossiped across the underlying blockchain network and the transaction, if valid, is accepted. Using our services blockchain client, we can listen for events, such as the transfer of an NFT. Here, we're using AWS Fargate to

listen to these events, and when one occurs, we can take some action, such as marking the NFT, on our site as sold. The user- pays architecture is what our customers running blockchain networks recommend to their customers. Next, we'll take a look at the unique considerations for building Web3 applications. Firstly, wallet and key security. As we saw,

if your application writes data to the blockchain, then it needs a wallet with funds. And the keys for that wallet need to be securely stored. We saw how AWS Key Management Service can be used to secure your keys. But if you have particular requirements, for example, if you need to manage the underlying hardware security modules yourself, then AWS Cloud HSM can also be used. But, and I can't stress this strongly

enough, you need to be storing your keys securely. Secondly, use separate wallets. The wallet you use for production should only contain enough funds to ensure your service can continue to operate for some amount of time. It shouldn't contain all of your

funds. In a few slides, we'll discuss how you can make sure your production wallet is kept topped up with funds. In addition to this, don't use the same wallet or keys across multiple environments. Have a set of keys for production, a different set for staging, a different set for development, and so on. Use a multi signature wallet such as Gnosis Safe for wallet that are used to top up your production account. Multi signature wallets are wallets that require more than one authorised party to approve a transaction before a blockchain network will accept it. This limits the impact should one authorised

party accidentally expose or share their keys. And because multiple parties must review the transactions, the risk of submitting a transaction with errors is lowered. For your smart contracts, ensure you have an upgrade plan. Contracts, once written to the blockchain, can't be changed. Over time, you may want to add, change, update, or even remove functionality in your contracts. There are a number of different ways to do this and one popular method is to use the proxy pattern. We have a contract that acts as a proxy - it forwards

function calls to another contract. We can't update the code in the proxy contract, but we can update the variable that tells the proxy contract where to send function calls. For example, if we have our proxy contract sending calls to contract A, and we release a new version contract B, we can tell our proxy contract to now forward all calls to contract B.

If you're using third party contracts, or contract libraries, you should have them audited by a third party. OpenZeppelin is a popular choice for audit contract libraries. Be aware that your contracts are also public, and that any vulnerabilities are visible to bad actors. Consider having your

contracts audited by a third party before deploying them. DevOps - in your different environments use different blockchain networks. In production - use a mainnet, in testing - use a testnet. In development - use a private or a locally hosted network. Once again, make sure you have a plan

for upgrading your contracts, and make sure that plan is reflected in your CI/CD pipeline. If you're using the proxy pattern, make sure it forwards to the correct contract, and make sure you have controls around how that address is updated. Popular Web3 tools such as ganache, truffle, hardhat, can also be used with continuous delivery services like AWS CodePipeline. One of the unique challenges with the

service-pays model is keeping the service wallet topped up with funds. We can leverage our monitoring and observability service, Amazon CloudWatch, to keep track of wallet balances, and to send a notification to the relevant parties when a wallet requires funding. First, we send a transaction to the network. We wait for the confirmation of that transaction. We can then check the wallet balance. We push this balance to CloudWatch. We can trigger an alarm when the balance is low, and use Amazon Simple Notification Service to send a notification, an email, an SMS or a Slack message to the relevant parties, who can then act on this alarm. For

scaling, cloud scaling best practices remain the same. If your application is limited by the read-rate of your blockchain client, in most cases, you can scale your way around this by increasing the number of blockchain clients. Depending on the specific blockchain you're building on, you may encounter a bottleneck when writing data to the blockchain. If the network is heavily utilised, you may see

delays in your transactions being processed and confirmed on the network. The first thing is to minimise the number of writes that occur on the blockchain. Depending on your specific use case, it may make sense to move code from smart contracts back into your service. Where possible, decouple rights from finality. Move to a more event-driven

approach where blockchain transactions are involved. And lastly, consider layer 2 scaling solutions. Layer 2 scaling solutions use various methods to increase the number of transactions per second. For example, if your application

needs to process a high volume of transactions between users, layer 1 Ethereum can only process 10s of transactions per second. Whereas a layer 2 service like ImmutableX can process 1000s per second, and for free. Web3 is built on blockchain technology. Blockchain technology is

designed to be trustless and able to be run by anybody, which naturally means that blockchain software is open source. Amazon is relentlessly customer focused with 90 to 95% of our roadmap driven by customer needs. In blockchain, open source matters to customers, so it matters to AWS. Amazon is constantly pushing forward in the open source space, and we actively contribute to open source projects and maintain a presence in a number of open source communities, such as GitHub. Our goal is to ensure that AWS is the best place for our customers to run the latest open source solutions. Whether that

is directly through AWS services, via partner solutions, or within customer developed code. Here are a few links that will help you get started on your Web3 journey today. You can go deep and get hands on with Amazon Managed Blockchain. You can follow a step by step guide to minting and deploying your own NFT's, and you can join us in the new Startup Loft, a community where startups can connect with AWS experts. To

continue your cloud journey, please use these training resources. Right now, there's a course on AWS Skill Builder called Introduction to Blockchain that you can access and get started with today. I hope you've enjoyed today's session. Please feel free to reach out to me using the details in this slide. We really value feedback to help us improve our sessions. So please complete the session survey. Thank you.

2022-09-10 23:38

Show Video

Other news