 Okay, here we go. Hi, hello everyone. So thanks for spending the Friday evening listening to how to build a web tree. So my name is Edison from Akiles. And Akiles is a marketing technology company based in Singapore. We built software solutions to make marketing more efficient and transparent. And the reason why I'm giving this talk is because as part of the technology stack that we use, blockchain is actually a very important portion of it. And I'm in this blockchain space for the past three years, starting all the way from grad school where I was researching on blockchain and my first job in Zulika, which is a public blockchain based in Singapore. So I'm here to share with you what I've learned about this amazing technology and what it takes to build an application on that. So the agenda that I'm going to cover today is very briefly is what is a blockchain from a software engineer's perspective. And also getting started with some tips about how you can build your applications on a blockchain like Ethereum. So starting from a very high level question is that I think many of you already know how to build a simple application. It can be as simple as a web application and you know how to make certain requests and response. But how is it good? And so how is blockchain different? So let's go back to the fundamentals. I'm a little bit of a puree. So to me, a blockchain, the definition of blockchain is this. And it is from a Bitcoin white paper. Because after being in this space a while, you start to see that many people claim that they have a blockchain but they don't really have this concept of blockchain. So it's kind of like strange. So we start off with this problem of transactions. So transactions in a very briefly is that, let's say I want to send you a Bitcoin. What happens is that I use my private key to sign a transaction and we get a signature. And if someone else wants to pass on that Bitcoin to someone else, then you will sign on the hash itself. And along the way, we can always verify based on the chain of signatures and trace it to verify whether if someone has a blockchain or not, has a Bitcoin or not. And so after all of this is done, because there is a transaction kind of like sequences. So we go on to the blocks. And on every block on the Bitcoin network, which usually is usually one block every few minutes, you get a block with multiple transactions inside. And at a high level, there's a previous hash of the previous block and the nonce of the new block. And you go on and go on and go on forever. And it is an infinite state machine. So first forward six years later, so Bitcoin came in 2009 and in 2015, there is Ethereum. We started to get introduced to this concept called smart contracts, which is I think where most of the exciting things come from. Smart contracts are basically pieces of computer code on the blockchain that automatically executes itself. So if someone wants to say that, all right, if only this condition is met, then I authorize the payment. So contracts and users can send transactions to each other. So smart contracts can call another smart contract. And users can also call a smart contract to evoke certain functions. So we go on to move into what is Ethereum, which is like an infinite state machine. So let's begin with the first state. So let's say everyone has $100 in the ledger. And we make a transaction called at least transfer $50 to Bob. So on the new state, the state will be changed. And this goes on forever. And all this transaction and this verification is agreed by a global network of nodes that are operated by miners. And this is modified over time by transactions. So in a more technical and more theoretical way, and this is it, what we call is an infinite state machine is because whenever you have transactions in, the state changes and the state changes over time. So it is one of the concepts of computer science of state machines. There are infinite state machines and there are discrete state machines. Why am I saying this is because it's very important for the subsequent thinking around how you reason about smart contracts. So I think where the exciting things for software engineers is that blockchain and smart contract programming is interesting in this view is one smart contract is complex. So a piece of code, which is like maybe say 20, which could be as little as like say 30 lines all the way to 300 lines. It is quite rare to even see a smart contract that is like 1000 lines. And this smart contract has to do a lot of things. It must be able to store data. It must be able to declare functions. And it must be able to do manipulations and aromatic like addition, subtraction, modification, etc. So this 1000 lines of code, which is going to be very little compared to what many of us are used to in our daily work is that it contains a bunch of logic and it can get quite complex over time. So being able to think about this in the timeframe of like, I think you do so many things in this 1000 line. How do I do it in the most effective way? It's one of the challenges here. And also the second thing is that because when a smart contract is being deployed, it is like a honeypot on the Ethereum. There's just so much money there. And if you're not careful with how you program it, then that's where money can be lost because on the Ethereum blockchain, it could store like cryptocurrency and this represents money. So this is actually something that the developers have to be cautious about. The scary thing is that as developer, we only know how to prevent ourselves from bugs when we can foresee this. Like for example, I can only write test cases that I think that this will go wrong. But we do not know exactly what will, so we may think that we know what is going to go wrong. But we also do not know actually what might go wrong. So what it means is that you might, because if the developer missed out on some test cases, that's where things break. And on the blockchain of smart contracts, this could be disastrous. So in three lines, what makes development on blockchain different is that smart contracts are very complex and it must be able to store states and able to communicate with other smart contracts. And also transactions are not free because the computations needs to be calculated ahead of time. So you need to know how much guess or how much credits, you think of guess as a credit that you want to allocate the sufficient amount so that you can call it. And blockchain is immutable. So once you push a new code out there, you cannot update it as simple as let's say patch the version. So you need to be very careful of what happens when you push a code to the blockchain network because if there's a bug, it's very hard to fix it. So those are the few things here that I think is very interesting about blockchain and also from the perspective of application developer, I mean I came from the background that I do both. We have applications and we have a blockchain component. So sometimes I have to learn how to change between two mindsets. All right. So starting with very, very particular things about how do you get started with blockchain smart contract programming? The one on the left side is where we are most familiar with. So you have a web dashboard. You point to a server. You point to a database. And this is what most software is. But on the blockchain network, right, you could connect directly to this network of nodes all over the world. So on this blockchain itself, there are going to be things like smart contracts and there are going to be things like accounts. And it is very complex. And what do I mean by complex? So if we try to draw out the entire workflow and the state transition of a smart contract, it could start with this. So let's say I'm account S. I could make a transaction to a smart contract C. And the smart contract C could call multiple transactions to contract D. It could send out some tokens to account Y. It can invoke another smart contract called contract E. And this can go on for a certain amount of debt. And also sometimes, let's say if you call contract E, the contract E can also re-enter contract C again. So this means that when you want to actually make sure that you don't, your program correctly, you also must draw a similar state transition graph because there are some history where the one on the top right, that is actually a real security flaw that happened in 2017. Interacting with blockchain using wallets. So if we go back to here, like going back before, I mean that transition on Caspian was great because you have an authentication part. But for a blockchain, how do you authenticate? So that is being sent directly when you have a presence of a private key. When a private key is just a bunch of hexadecimal string over there. And what it generates is that it generates a public key, which will allow you to be able to verify your identity on the blockchain. And the private key also helps you to sign transactions. So let's say I want to send Microsoft a mile of Bitcoin or Ethereum. Then I will need to sign a transaction with my private key, point it to a Microsoft address, and that's how our transaction happens. So going into this is that if we have an application, this web application usually interacts with a blockchain through an RPC. So it's not like a magical thing where you have to run a blockchain network or a node on your computer. So you could point it to some hosted services. This slide is on Zorica, which has its own ways. But on Ethereum, there are services like Infura that can provide you with these hosted services and an interface that you can call easily. So this is how you can actually build a web application. So going into Ethereum use case, right? So let's say if you have a client application, a front-end dashboard, what you will do to connect to a web tree is that you can choose to ask your users to install a metamask extension. So this is like a Chrome extension that is on your browser. You can stick in your private key and you can actually use that to actually interact with web tree familiar applications. So recently on Forbes, right, you can actually pay using Ethereum. So if you want to pay for a subscription on Forbes.com and you have this metamask extension enabled, you can actually authorize the payment. So all these things does not require you to pull in your credit card number. It's very fast free. And it is not just powerful for just sending Ethereum or paying for microtransactions. Why is it microtransactions? It is also useful for providing identity. So I think that once this actually takes off, microtransactions can be a thing because on the internet world, credit card transactions are very expensive. Not sure if anyone here is from Stripe, but Stripe earns a lot of money just by processing credit card transactions. So we hope that that will go away someday where transactions can be in the fraction of a cent. And that's how Zilliqa transactions are. Everything costs less than a cent. So you don't have to pay for this hefty credit card bills. Okay, so and all these things we're actually interact with like you can choose to interact with a local testnet for development that will allow you to test your application and making sure that it's production ready. And once they're ready, you can push it to the main Ethereum network. And this can be either you host your own note, which is a gateway to this network, or you could use a hosted service like Infura. So this is like maybe like a more illustrative kind of like tinged with a more advanced concept called IPFS. So let's imagine that I'm trying to build a Twitter application on the decentralized application. So this is how I'm going to build it. I will use my standard ReactJS application as a web front end. I'll collect certain things like the tweet that you want to make as a stream. I will allow you to upload a picture. So once that is done, right, I will actually send it to the IPFS, which stands for Interplanetary Fault System. It is a decentralized file system that allows you to host like image. Think of it like S3 bucket, but on the decentralized web. So Amazon S3 bucket, so like a dropbox. So when you put your files there, they will turn you a hash, and you can put a hash on the Ethereum blockchain to show that this is the content that I have, and this is the sort of like URL, or IPFS URL to that image there, because the whole idea of blockchain is decentralized. So let's say if you put it on AWS or you put it on Google, one day they may take it down, or one day you may get censored or blocked by a domain. But if you put it on the blockchain and the IPFS, it's very censorship free. This will return a result. Once you put it into Ethereum, you get an Ethereum hash, and that's where you can display to your user that, yes, I've received your tweet and a picture. This is the hash that is being on the Ethereum blockchain. Whenever people want to, say, interact with your content. So let's say that maybe your tweet has a donate button. What you could do is that you may have a Node.js server, and this Node.js server could also receive events from the Ethereum blockchain, like a socket connection. So this is where you can actually receive things like push notification through, and also push it back to your front end. So some things are good for the blockchain, but always remember that blockchain is not suitable for storing everything. So some things to my store in the standard MongoDB. So I usually like to tell people that blockchain is an extremely expensive database. It is not ideal for storing big data or doing all kinds of, like, saying a large transactions. I mean, it's cool that people put, like, banana trails and audit trails on the blockchain, but you should try not to do so much of it because it can get pretty expensive. So yeah, so this is an overall view of how I will build a web front end. And I think maybe I just want to just go very briefly into some of the security attacks because I think security is one of the most important topics to cover in smart contract programming. The key question here is the answer is that are we safe in this smart contract space? So in the past few years, we have seen quite a lot of things like the DAO attack which happened in 2016. That's where a re-entry C attack. So going back to the complicated graph, like someone sends to a contract. The contract sends to another place and re-enters a contract. That's the DAO attack, which I have an illustration for that later on. There's a parity bug where someone accidentally frees a multi-senature contract. And so far we have been good that I think that I should have updated this slide with the 2020 because recently there was another smart contract that got exploited and multi-million dollar is being lost. So it can get quite sophisticated over time and I think that this will always go on. So this is like based on my research paper published by NUS. It says that all the smart contracts out there there are quite a significant number of contracts that are vulnerable. So there are plenty of things if you're coming from the angle of cybersecurity there's lots of things to do on the smart contract portion. So going to this, this is exactly what happened in the DAO attack and how things may go wrong. So let's say that I have a fundraising contract and it means that I just want to get the amount of funds from the contributors and I say that, and I'm going to reset that to zero. I'm going to send some money from the sender to an account and you call another, you try to send a transaction to a person. So usually this means that I will be sending money to a person. But in this case, what happens is that someone actually instead of like, because this quote actually works if that recipient is a user. But this quote does not work so well when the recipient is not a user account but it is a smart contract. So in this case, what happened in 2016 was that someone discovered this exploit and they wrote another smart contract to basically point it back to here. So as you can tell from the last line, that's where the contributors get to zero. So that's where you reset the balance back to zero because whenever someone calls this and you just enter a loop all along and the contributors amount never gets to zero and that's where the attacker is able to drain the funds from the smart contract in real time. So the DAO is like a decentralized venture capitalist. So people actually put money there and they could actually invest in other projects. But because of this, you can see that the Ethereum and Ether has been taken away in real time and it's like watching a bank robbery in real time and you can't do anything about it. So this is something that's pretty interesting. Also just to share very briefly on a few other exploits is that what we call transaction ordering dependence. And this means that if we have two functions, update price and buy, the sequence of which goes first changes depending on which transactions get ordered on top because it's a decentralized network so you can't control which order it goes in. You can only control how much gas you want to put in. So there are ways that you have to make sure some transactions are before other transactions. So finally the last thing is that because transactions and computations are expensive on the blockchain so you need to be very careful about your resource consumption. So what happens if you do not actually do that? So let's say that I have an array that just keeps expanding over time and I say that, okay, whenever I try to empty an array so whenever I want to win this lottery, I need to empty this array. But it may just be that whenever I want to empty this array, this may cause too much gas and it may be beyond the gas limit of a certain block. So this might not be able to happen. So same thing as your programming on the smart contract, you have to be aware of the limitations of the blockchain network and how you master concepts like gas and transaction dependency. So I guess that's it. So there are just like lots of things to cover but I just want to share with you some of the more interesting things that will hopefully ignite your interest into blockchain programming and feel free to ask me any questions. Thank you.