JS GameDev Summit

JS GameDev Summit 2022

Web 3 Gaming: What it is and Why it Matters

Paul Gadi

React Advanced

React Advanced Conference 2021

Web3 Workshop - Building Your First Dapp

Nader Dabit

JS Nation

JSNation 2022

Build Web3 apps with Javascript

Shain Dholakiya

React Summit

React Summit 2022

How to Build UI's for Smart Contracts

Rahat Chowdhury

Build Blockchain dApps using JavaScript

Hello, my name is Russ Fustino and welcome to Build Blockchain DApps Using JavaScript. I'm a developer advocate for Algorand. So blockchain devs need to know, you know, first of all, what is a DApp and how can I build one as well as what kind of solutions can I build? I know when I first started doing blockchain development, that was a question that was first and foremost on my mind. What kind of solutions can I build? And what programming languages can I use to build DApps? How do I verify smart contracts, in other words, audits? So the agenda for today, we're going to cover Algorand blockchain layer one, do a little bit on setup, meet your development environment, and then creating a simple DApp, which by the way, stands for decentralized applications. And we'll cover verification as well as some UI controls from pipeline. For those that are brand new to blockchain, what blockchain is, it's a mutable decentralized ledger consists of blocks, which are periods of time, and then the transactions that are associated during that time interval. Now, of course, transactions are between a sender and a receiver. So those would be your accounts. And each account has the association of assets to it, as well as applications. Now assets can be your fungible or non-fungible tokens, and applications are smart contracts. So with Algorand, we use a pure proof of stake protocol. The pure proof of stake protocol is extremely quick, and it really scales. Last peg, that 1,400 transactions per second and block times created in under five seconds. But not only that, there's infrastructure longevity. The entire project is open sourced, and a lot of technical flexibility with all sorts of SDKs and tools being created and available for developers to build blockchain solutions. Transaction certainty, there is no forking in the Algorand blockchain, very extensible platform as well as extremely energy efficient. It is actually a carbon negative blockchain. And cost efficiency, cost of a transaction is less than a 20th of a penny. Also provides true security, because it is a read only, write once ledger that is distributed across the globe. DeFi is by far and away the biggest vertical market or type of solution that you can build with Algorand blockchain. Stablecoins. So what stablecoins are is still crypto, but they are tied to a US economy. So as the US dollar goes up and down, so will the coin. So it fluctuates the same as the dollar does. So over 3 billion in circulation there you can see for USDC. Then we have decentralized exchanges or DEXs, things like TinyMan, AlgoDEX, AlgoFi. What's happened here is that up until now, you've had to go to a bank to use financial tools. For example, say you want to create a stock portfolio. Well now the same tools are available to anybody that wants to use them. And you can go to sites like these and apps like these to be able to create liquidity pooling and staking and a lot of other things. The Italian Society of Authors and Publishers, another great implementation of blockchain, they're using NFTs to identify copyrights. So NFTs are unique. And you can see here they've put over 4 million NFTs on the Algorand blockchain to close to 100,000 creators. Really this is the future of the industry for doing copyrights. Just think about it. There's no global boundaries. And it's accessible to anybody that wants to have access to it. And other use cases, the list goes on and on here. A lot of different verticals, mostly every vertical market that really has a use case for a blockchain. Let's get to the next section here on the heart and soul of your solution, which is layer one. Algorand accounts, ASAs or Algorand standard assets, atomic transactions, Algorand smart contracts, as well as reporting with indexer. So first you have a standard account, which could represent an individual, let's say, for example. And then you also have a multi-sig account, which could be representative maybe of a board of directors for an example there. Now with a multi-sig account, you do have the capability of finding a threshold. In other words, how many votes do you need out of the group here to pass the transaction or to sign it? And then a logic sig, which you see on the right, or logic account, is a smart contract. So that either returns true or false. And if it returns true, it'll go ahead and sign the transaction. If it returns false, it will not. Now we'll talk about fungible tokens and what these are exactly. So ASAs or Algorand standard assets can be either fungible or non-fungible tokens. So what we see here is a list of examples of fungible tokens. So things like stable coins, loyalty points, system credit. Each unit of the cryptocurrency is worth exactly the same amount. And there could be several of those. Then on the NFT side of things, with non-fungible tokens, these could be used for in-game items when you're playing games. You got real estate, identity, certification, collectibles is a big item. And that's really the best way I like to think about NFTs is the fact that they are like a collectible. They're unique. They're one of a kind. So some folks I know collect baseball cards, for example, or coins. Every one of these is in a different condition. Each one of these is a different rarity. Each one of these has a different trait to it. So these are all different, a bunch of different metadata that can be used to differentiate these. And they're each very, very unique. So let's take a look at creating one of these. I'm going to bring up algo.desk.io. This is a visual tool. So let's go and use one of our three wallets that are available here. We've got algo signer, which is a plugin to Chrome. My algo wallet is a web-based wallet. And then the pair wallet is a wallet that's based in Android or IRS. We'll go ahead and use the algo signer here for the demo. We'll go ahead and sign into our wallet. And I'm going to pick an account that's in our wallet to go ahead and use to create these assets. So what we're going to do now is we're going to create an ASA. So we have the ability to create a name test. Let's give it a new name of pizza. After the very first transaction in Bitcoin was for pizza. Now if I make a supply of one, that would be an NFT. So what I'm going to do is actually create a fungible token. Let's create 100,000 of these. You also have the ability to put a decimal point in there. Also you have the ability to put a URL that might be associated with this, more information, and then also a meta-hack. So next up, let's talk about Algorand atomic transfers. So this is where all must succeed or all will fail. You have a person A, for example, wants to send 50 algos to person B. And then person B in return is going to send a concert ticket to person A. Now when we used to do this through things like Craigslist or something like that, it was always a crapshoot whether this actually was going to work or not. Sometimes you'd pay the money, but you wouldn't get the ticket. Here this guarantees the exchange of goods is what atomic transfers actually do. And so this really does facilitate and really is the secret sauce for many solutions that are built with decentralized applications. Very easy to do and it's secure. So some examples of this would be simplified expedited settlements, circular trades, group payments, instant settlement for complex multi-party asset transactions, distributed payments. And again, these could be utilized with all the other layer one features of Algorand standard assets and smart contracts. Speaking of which, smart contracts. So this is the transaction execution approval language is the assembly language that's used. Short name for that is Teal. And it's assembly because it's very lean and mean. It's got to perform on the blockchain and be very, very scalable. So there's nothing leaner than assembly to do that. And then you have a Python enabled compiler, which you can use Python to generate Teal. And also JavaScript is used in a product called Reach. And there's a new Visual Studio extension as well and using C sharp to create Teal. So these are all basically Teal generators as each one of those products I just listed and more are on the way. Smart signatures basically approve spending transactions and then smart contracts themselves provide the transactions and facilitate both global and local storage. Local storage would be at the account level. Global storage would be at the blockchain level. These are all combinable with other Algorand technologies, including atomic transfers and Algorand assets. To wrap up DAP architecture, basically you have a UI front end. Perhaps maybe there's some smart signatures going on there using the Algorand SDKs or REST APIs. And then you got three different transaction types shown here. You have a payment transaction would be between your accounts. Asset transactions would be revolving around NFTs and fungible tokens. And then application calls would be your smart contracts. And those are facilitate local state and global state out to the blockchain. So the index is basically just a PostgreSQL database, which offloads the AlgoD process. And then it's indexed and searchable and a lot quicker and responsive. So it's a really nice reporting tool. OK, next up, we're going to cover setup development environment. And what's involved there? Well, the first thing you want to do is go out to the developer portal, developer.algorand.org, an award winning developer portal in the blockchain space. And then also Algorand Discord, you want to sign up there. And it's really great for support and getting your questions answered. And then also there's a Discord server as well for reach. And I've got both of those on here as well. The first thing I want to do is get the sandbox loaded up. Very simple. Just create a Docker instance and then clone the GitHub repo for the sandbox. And then also the Vultr private network, which includes Indexer, which is doing a sandbox up. It also supports other networks, the beta net, test net, main net. These are all supported with the use of the sandbox. So mentioned some SDKs. Those are the ones that are highlighted in red are supported by Algorand. The ones down below it, Rust, PHP, Dart, C-Sharp, Swift, and some more are supported by the community, the ecosystem. A lot of great tools on the right, including AlgoDesk I-O. You saw that as well as Algorand Studio. Algodilla is a really great tool as well for doing very quick development with minimal amount of coding. So with PyTL, basically this is what you have is the Python. And then you compile it and it returns the TL. And then both TL looks like there on the right. Great PyTL course to go out to YouTube. There's a nice playlist there. Excellent work there by the instructor. So your first transaction, let's go ahead and take a look at this in JavaScript. We're going to bring up this page here on the developer portal. And you see scroll down, it gives you the step by step on getting started. This is where you install the sandbox. Like we talked about, this is where you install the SDK for JavaScript. You can see the information there. There's videos on each one of these. There's also a Try Me live demo right here that you can click on and just hit the run button. You'll see it all execute. And then you start getting into the code and creating accounts and instantiating your clients. That brings us to Reach. What is Reach? Well, it's a programming language. It's a high level language. It's also a compiler and it does deploy your dApp to blockchain. So the focus is on the business logic. So Reach programmers don't need to think about the details of things like contract storage, protocol diagram, state validation, network details. So you have the back end. We'll start there over there on the right. You can see this is responsible for generating and deploying the solution to the blockchain. Also it interacts with the smart contracts automatically. So it's a solution implementation. It defines the interfaces for the front end that you're going to be talking to. And you define things like participants and APIs as well as verification and commitment. On the front end, now the front end can be done, the back end is like JavaScript like code. All right. And on the front end, this could be done in Python, Go or JavaScript or C Sharp. And basically what you have here is a user interface that is provided. And it does things like create accounts and a lot of traditional Algorand SDK methods. And you can also put blockchain specific code in there. So if you have something that is slightly different between blockchains, you can tweak that a little bit on the front end as well. You can compile it, run it, and then deploy it out to the blockchain. All right. It's pretty easy to install. You just bring up Docker, download a Reach executable. And if you're running this on Windows, you would need the Windows subsystem for Linux. And then also this is the code you write here. You go ahead and create your directory for the project and then you curl the Reach executable down giving it executable rights. A simple DAP walkthrough. So this is the back end file we're looking at here. So either player, Bob or Alice, gets the fingers they played and gets a guess and sees who won the winning game. And you can see that up at the top is really that's just the interface of the methods that are actually defined on the front end. And then also you have the participants that are involved, right? So they get fingers thrown and total guess and publish them. And then commit means you're done. You're committing that out to the blockchain. So the back end now also continues with rules and outcomes. So this is the logic to a game. I've got a game I'm going to show you here, Mora, where you're throwing fingers and a guess between the two opponents. And if either one of them guessed it correctly, then they win that particular match. So by doing this, everyone agrees on the rules for the outcome and everyone sees the outcome of the engine that we have. Now on the front end, this is you take the common number of 10, for example, into whatever native platform supports. So it takes like 10 algos, for example, you convert it to micro algos. And then you have the ability to create a new test account in the dev environment with that starting balance. And then you see down below, this is where Alice is deploying the contract. And then Bob's going to attach to the contract, in other words, opt in. And then we go ahead and run the game. And then also, these are the interact methods. So we saw the interfaces to these on the back end. And now this is the actual code in the JavaScript in the front end that this provides. So you can see we're just using some random functions here. Next, let's talk about verification. This is a very, very important topic. And this is what it does is it protects against blockchain attacks. And it guarantees things like the contract balance is zero. Because think about it, you're creating accounts on the fly, potentially in these contracts, and there you're funding them. And if it's created on the fly, it's in the contract, only that contract knows what the private key is. Right? No one else would know that. And if the contract ends executing and there's funds still in that account and haven't been exhausted, guess what? You're going to lose those funds. There's no way of getting at them because the contract gets done running, goes away. And that's a problem. That's an issue. And there have been some big monies lost in the past because of this particular problem. So what verification does and audits do is prevent locked away tokens by the contract and hence become inaccessible. So as far as auditing goes, the non-reach solution is an auditor approves that program with their own analysis. And they're doing the verification of a version of the program. I mean, if you've got a minor change, then the audit is useless for a prior version. They have to do everything from scratch. With reach, the compiler verifies. And then the auditor verifies that you provided to the reach compiler enough assertions. And code changes, well, the reach auditor just needs to check the right assertions were included on the code changes. So you see here, Alice shoots four fingers and guesses a total of five. This is just a demonstration of doing some printing on the back end. And then also, you see Bob shoots zero fingers and guesses four. So the actual thrown is four. And Bob wins the wager. And so you see his account value increases. What happens if I change this to just going one times the wager? So right now, you have two times because each player is providing a wager amount. So two times a wager is the total that's in the pot. So if we try to run this, it's going to realize that, hey, this doesn't work because you're going to leave money on the table. And now you can see some violations down below. So you can see here that message zero balance at application exit. That assert failed. It's not a zero balance. There's some stuff left in there. I have a solution I wrote up on the developer portal. Here's a link that really goes into detail, step by step, on building that particular solution that we just looked at. So that brings us to the front end, right? Pipeline UI, it's a vanilla JS SDK and React component library. And you can see here there are controls that are available that you just copy snippets of code and HTML into your solution. You can see on the right is an example showing an account, but not only the account number, but also a QR. Also, there are Algorand-specific React components as well. And we got Twitter spaces with Algorand Dev Twitter and follow our Algo Devs Twitter. So in summary, we took a look at Algorand blockchain at a high level, as well as some use cases, what you can build solutions with. And we looked at all the layer one features. Then we took a look at what was involved in setting up an environment. We took a look at Reach and building a simple DAP. And this is a fascinating product. It does build in things like verification as a good benefit. But again, you're writing it in a JavaScript-like code. The back end, the front end can be in JavaScript as well. And the verification process is very, very important there in building solid decentralized applications. And finally, we looked at the pipeline UI controls. Thank you very much.


Russell Fustino

GraphQL Galaxy

GraphQL Galaxy 2021

Building GraphQL APIs on Ethereum

Hello, my name is Nader Dabit. I'm a Developer Relations Engineer at Edge and Node. Today, I'm going to be speaking about building GraphQL APIs on top of Ethereum, but also the Ethereum Virtual Machine. You can think of the Ethereum Virtual Machine as like the React of the blockchain world. You learn this one skill set, and you can build not only on the Ethereum blockchain, but any EVM compatible blockchain, meaning a handful of different Ethereum layer 2s and sidechains as well as other completely different blockchains like Avalanche, Celo, and many others that are out there. With that being said, let's go ahead and get started. How we interact with and build on top of blockchains is much different than what we're used to in the traditional web. In a blockchain, data isn't stored in a format that can be efficiently or easily consumed directly from other applications or front ends. The problem is that you need to have the data indexed and organized for efficient retrieval. Traditionally, that's the work that's done in the centralized tech stack, but that indexing layer was missing in the web 3 stack. In the traditional web stack, databases, servers, APIs, they filter, sort, paginate, and join data before it's returned to our client applications, typically via some type of HTTP requests. These types of data transfer nations are essentially not possible when reading data directly from Ethereum or other blockchains. In the past, developers and teams would build out and operate their own proprietary indexing servers, but this requires significant hardware and engineering resources, and also broke the important security principles around decentralization. Around the year 2018, the graph began being built to solve this problem. The graph is an indexing protocol for querying blockchain networks like Ethereum and IPFS. Let's talk about how the graph works. Let's take a look at a couple of other indexing systems that we might be using in the day-to-day world that we're already used to. Search engines like Google crawl the Internet, they index relevant data, and they make it available for users like us to search via their web interface or their APIs. Without this indexing layer, it would be hard for us to know where to look and how to find relevant information across the web. You could think of the search engines that we use on a day-to-day basis like an indexing layer. Another similar analogy is a library. Using an indexing system like the Dewey Decimal System, we know exactly where to find the book that we're looking for without having to go looking book by book throughout the entire library. Using the graph, developers can build APIs called subgraphs. A subgraph defines how to efficiently index data in a deterministic way and make it available for querying from front-end applications. Subgraphs live in between the blockchain and the UI, providing an important piece of software infrastructure, a flexible performance and decentralized API layer. Once a subgraph is deployed and the data is indexed, apps can start querying the data without relying on any centralized service provider, and instead they can lean on a query marketplace that's comprised of a decentralized network of indexers, all competing to provide the best service at the best price. Right now, the graph serves over one billion queries per day, and many types of applications in the Web3 world are using it, including DeFi, gaming, NFT marketplaces, and a handful of other types of applications. To get started, you would go to the graph.com, and in the user interface here, you can go ahead and define the subgraph name along with any other searchable metadata that you'd like to be made available. Next, you would use the open-source graph CLI tooling to scaffold out a subgraph locally that you can then begin building on. Next, you would define the data model, which is essentially the GraphQL schema, the contract addresses that you would like to have indexed, and any other configurations that you'd like to have set up locally. The GraphQL schema would look like any typical GraphQL schema. The main difference is that we do have a couple of different directives that allow you to interact with the graph network like at entity as well as at derived from for creating relationships between different data types. When you're ready to deploy your subgraph, you can then run graph deploy. Then once the deployment is successful, you should be able to start testing it out directly in the graph dashboard. Here we have a graphical editor. We also have different logs for any errors that might have happened when you deploy your subgraph. Then when you're ready to query, you can just query it like you might have done from any typical applications. You can use a GraphQL client like Apollo or Oracle. We'll be giving you the GraphQL endpoint from the graph dashboard. Then you can just run whatever type of query that you would like and everything should work just like any other GraphQL application that you've probably interacted with in the past. With that being said, let's go ahead and go to the graph.com and see what this looks like. Here we are in the Graph Explorer. You can see that we can view all the other different APIs that other people have deployed. These are all completely open and public. If we'd like to view on, we can click on one, and we can see that we can test it out. We can run different queries here in the playground. We can view the graphical introspection here. Anything that you would like to know about a subgraph should be available here. But let's go and test one out. I'm going to go down here to search and I'm going to find the foundation subgraph which is something that I've created a couple of. Here we can go ahead and test this out. This is a subgraph that queries the NFT Marketplace Foundation. We'll go ahead and just run a query here. We can see that we have all this data coming back. We have this content URI. This is going to be something that we can fetch and use for finding all the different metadata for an NFT. Here we have the IPFS path. We can test this out by going to ipfs.io slash IPFS. Here we see that the data is indeed coming back. If you'd like to learn more, if you'd like to build out a subgraph yourself, I would check out the graph.com slash docs. I would also maybe check out this workshop that I've created at github.com slash dabit3 slash building a subgraph workshop. If you'd like to learn more about the graph, check out the graph on Twitter at graph protocol, the graph.com, the graph docs, or join our Discord. That's it. Thank you for checking out my talk and I hope you enjoy the rest of GraphQL Galaxy. Thank you.


#blockchain