 where smart contract developers are there? Well, the answer is not enough. We're mirroring a similar situation that happened in the early days of web development in the 1990s. We have high demand, low supply. Right now, we have around nine million Java developers and that's paled in conspiracy comparison to like the less than 10,000 blockchain developers and even less smart contract developers. And these smart contract developers are up against a lot and then here's one example of how they are. And so we created a smart contract life cycle and this is a grand departure actually from traditional software development life cycles. And I come from a project management background so I love the life cycles. We started the business model specifications. Currently, we're programming money essentially with smart contracts. That's a departure from traditional software depending on what you're programming and what you're building. But analysis requirements are standard, architecture design code, that's standard and then we get to systems testing. We are programming money and any bug is actually catastrophic to our business model. It ruins our entire business model. So we spend a lot of time in testing and we go through UAT testing, regression testing. We try to break these things and then we try to get it audited. That's also departure from traditional software development which is not a standard, but here it pretty much is. We get confident, we deploy it and then we support and maintain it. That's another departure. Support and maintaining is done by the EVM. There's no back office supporting visits supported by full nodes and miners. And so as a dev or business power user, really how to interact with your smart contract it's a minimal footprint. And you will have to support any bugs. And what does that mean? When a bug comes across your smart contract or you have to upgrade it or a feature, you have to run through this entire cycle again. Traditional software development allows us to just add features, upgrades, fix bugs and really just deploy it again. Here we have to create a new smart contract to fix anything or to upgrade it. And so that adds to the smart contracts that are retired but they're never really retired. And so we have a lot of them on the network. So there's more than 1.8 million smart contracts on the EVM that's closer to 2 million now and they're growing. So let's go inside the network. And so we got this information from Ethercamp and Etherscan. Since 2015 we've been slowly growing on smart contracts in the EVM and now in quarter three 2017 we've have more than a million in this quarter alone deployed to the EVM. And we project that it's gonna grow until we get 2018 where we have a million smart contracts per month. And if you compare that to blogging there's over 100 million blogs created each month. And so that's a trivial number when you compare that to these systems that already been abstracted and they're being used. And so what else are we going up against? Well, difficulty in start contract. So we have basic nuances like the differences between send transfer and call that value. And then we have more advanced nuances like re-enters the issues. And so all this adds to creating, going back into that smart contract life cycle and running through it over again because you have to add a feature or fix a bug. And so how do we enable rapid smart contract development? Well, we need to abstract a few things from here namely this portion, right? And this is gonna help average users to use this platform. Now, Alex Vandesan said that the average user is just a mythical and elusive creature but that's not true because we know who the average user is. And so the average user is really developers. They're highly technical. And a small portion is just the consumer, Chad. And so we have to develop a platform that targets all three of these to enable rapid smart contract development and mass adoption. And so how do we do that? Well, we start small. We crawl there, right? We do templates. These are very easy, just fill in the blank templates. Very one use case, they do it very well and that's it but it's too narrow and that's not enough. So what's the next step? Configure smart contracts. You basically take that template and you add features and additions to it so you can just switch on and off what you need but that still isn't enough because that is still a rather narrow use case. And so what's the next step? Smart contract creation via a GUI. So what we can do is throw a template or throw, I'm sorry, we can throw elements of GUI onto a canvas and we can abstract code from it and develop our smart contracts. And then reverse, we can take our smart contract, upload it into the platform and develop a GUI from it so you can interact with your smart contract. And so we've answered the what and the why and well, now we gotta answer the pow. Hello everyone, I'm Matt Suizi, founder, product lead and developer at Pactum. How would one build such a platform to further encourage mass adoption and enable rapid smart contract development? First, let's do a quick user error. I'm sure many of you have seen and recognized this diagram. This platform needs to be able to receive, store, analyze and compile a solidity and viper source code as well as capture the generated ABI and byte code then be able to sign and submit transactions to the EVM. There's nothing new here. What is needed is an interactive friendly UI to allow everyday people that are not developers to build out and deploy smart contracts to meet their unique needs. At the same time, this platform cannot forget about developers more than that later. Now let's explore the platform layer by layer. The platform needs a killer UI and an intuitive and cutting edge UX that is a must. The UI needs to be desktop and mobile friendly thanks to dozens of front end libraries, frameworks and templating engines such as jQuery, Angular, Bootstrap, Mustache and various others. Building such a UI won't be much of a challenge once the design has been established. Required at the client side is Web3, JS implementation and third party wallet integration for outside wallets such as MetaMask to allow users that control their own wallets directly or indirectly to sign and submit transactions. Mobile developers, web app developers, back end developers, front end developers, blockchain and finally smart contract developers. There's such a vast amount of skill sets out there, it's impossible to master them all. The API layer of the platform will enable any developer to harness the power of smart contracts without having to wrestle actual smart contract code. This layer of abstraction will empower regular websites and applications to deploy, execute and query the EVM without needing to do actual code development themselves saving time, money and stress of learning a new skill set. Moving on to the meat and the potatoes of the platform. The middle layer of the stack or the back end of the platform is what connects the UI API to the EVM along with running other methods and business logic. To interact with the EVM, the middle layer needs to leverage Web3 JS for JSON RPC calls to the EVM nodes. Luckily for us back end developers, we have Java and .NET libraries such as Web3J and Ethereum to import into projects as dependencies limiting the need to code direct Web3JS integration. Developers can now call Java and C-Sharp methods to interact with the blockchain. Now, what are other features this should be extracted to accelerate smart contract adoption? Username to wallet address association. So we've learned how ENS works, but now for contact information. So it says phone numbers, emails, usernames can be used instead of handling 40 character hexadecimal strings if you exclude the prefix. With these associations, users will now be able to have a directory look up and keep their own private address book on the platform. Another example is wallet management. Wallet generation, security and handling. For new, non-tech savvy users, are those wanting to be lazy and not worry about handling their private keys? This is not the preferred method though amongst early adopters, but for mass adoption there must be a middle ground to encourage new user growth. And finally, to the EVM node layer. The platform should have its own local Ethereum clients, one to support the both the testnet and mainnet networks. And also in order to deploy, execute and query smart contracts, as well as send transactions if the user is utilizing the platform's user wallet management system. Now here's the stack as the layers come together. Now let's run through a non-developer user story to see how the platform stack is utilized. Now say, users come into this platform's desktop or mobile UI and they want to design a DAO smart contract. Well, they would drag and drop UI elements onto a canvas. Let's say the first one they'd drag, pick, select, is a UI element representing the board of the DAO. Now after they drag it onto the canvas, they should be able to click on the element and then configure. What should they configure? Well, let's for example say how many board members total there are or what decisions require a majority or unanimous votes. How are board members added, removed or replaced? Now after completing the design of the DAO, the user will know immediately if their design contains any errors. Once error free, the user will be able to deploy the DAO smart contract to the testnet or directly to the mainnet. The steps involved here can be contained in the user's browser or taken to the middle layer of the platform, depending if the user is utilizing their own third party wallet, which is preferred, or if they're utilizing the platform's wallet management system. Now, okay, let's move on to a dev user story. A developer comes up with the most amazing ICO smart contract and wants the community to utilize their design. They've come to the platform's interface, upload the source code and viper our salinity. The platform will then check for errors, compile and generate the ABI and finally parse out the annotations to generate the UI interface. Now the developer can publish this configurable smart contract now to the public allowing someone like a Chad to launch his own shit token with minimal effort and no coding. This is an intro, all right. So closing thoughts here. Here's a great visualization of what this platform is striving to achieve at a high level. We want mass adoption of Ethereum's smart contract technology, right? This is possible through abstracting smart contract development away from non-smart contract developers and non-developers among the use of the platform. Users enter the platform through the UI and API layers. This allows for SEC, CSE and CSTTs to be consumed. Now smart contract developers will also enter through the platform's UI, upload smart contract source code as stated before, have UI auto-generated through the use of parsing the ABI and also through new development methods and ideologies we will introduce through the platform such as annotations that allow auto generation of the UI. And if they desire to, they can publish this source code to the platform's library and now that smart contract is now a configurable smart contract or a smart contract template that your average user can consume. Now we talked about how the platform's gonna do it. Now there are some responsibilities that this platform should take in encouraging mass adoption. One is education. We want to promote user growth. So we need to educate new users on what a blockchain is, what trustless agreements are and how programmable money currency can improve their lives on a daily basis. Also involved is protection. We need to prevent and stop attackers and scammers as much as possible, especially as new users come in, they're very naive, y'all I'm sure get Slack, emails, spams, all that about check your wallet, check this fake leak to Mew and upload your private key. They're gonna fall for that, but the average user will because these emails are more and more on a daily basis, getting more official looking. One way to stop this is to blacklist proven bad contract addresses or wallet addresses. Now this can range from different levels. One, you can notify the user like, hey, you're about to send transactions to a known bad wallet or smart contract address or if the user chooses to through the platform, they should be allowed full protection and then the platform should completely block their transaction and then notify them why the transaction was blocked for their protection. Now people browse the web every day. Most do not realize they're indirectly using TCP and IP protocols to visit their favorite sites. In five years or so, this platform should achieve the same result. The average user will be extracted away from the protocol and essentially never knew they were interacting with the EVM. Thank you.