 Hi everyone. Thank you for coming. My name is Alex. I work in Smart Deck. Hi, and today I will tell about one of our creations, ERC-20 test suite and how it helps in achieving the decentralized security. To start with a couple of words about Smart Deck. So we've been working in the area of application security for maybe 10 years now and the five years of those, we are creating application security tools, both for small businesses and big enterprise businesses. And in the area of blockchain security, we perform more than 200 blockchain audits. And of course, we create a number of smart contract security tools. And during our work in blockchain, we encountered the following problem. Many blockchain projects, like some DAFs or exchanges, deal with tokens. And most of those tokens are meant to be ERC-20 compliant, but the sad truth is that most of them are not. Currently, if you run some of such projects, for you there are only two approaches to ensure the ERC-20 compatibility. It's either ordering a third party code audit or writing a bunch of tests. So both of these approaches take long time, they are expensive, they need a certain degree of trust and of course they are not scalable. So according to our vision, if you work in a project that deals with any counterparty interfaces that need to comply to some requirements, you need to have a way to check these compliance in a decentralized way. So as a first step in achieving this vision, we created the tool that we named ERC-20 Test Suite. Basically it's a DAF, it runs tests on chain, it saves the results on chain and it is completely trustless since it's a smart contract. It has simple web interface, but it can be used via smart contract. So I will show you how it looks like. So the process is really easy, it has only three steps. You enter the address of token, you approve 1000 token units in order to perform some checks. And please know that all of those tokens will be refunded to you. And on step three you click yes, okay, please check this token. And after a couple of minutes, after the transaction is mined, you see the results. It's basically it's a list of properties grouped by type and they are color coded to show whether the concrete property is violated or not. So these same results are written on chain and can be accessed by any smart contract at any time. So what do we get? We get low price, you pay only for gas. The process is fully automated because no people involved at any moment. And those tests are really easy to run, you saw it. And the results are easy to understand and easy to show to anyone. And not to say that we achieve trustlessness. So please go and try it. It's online, it's testsew.net. And also we open sourced it and it can be found on GitHub. So you can play with it and maybe change it according to your needs. Thank you. Hey everyone, my name is Tim Beko. I'm here to talk about how we can fund ETH 1.x by auctioning off the names to Ethereum network upgrades. So bit of background. There's some initiatives on Ethereum 1.0 and Ethereum 1.x that don't get the funds they need to get off the ground. And oftentimes the amount needed for these initiatives are quite small to basically to build a proof of concept to get to an initial heap and something like that. So I think we could fund some of these efforts by auctioning off the names to network upgrades. So what I mean specifically is I think we could run an on-chain auction from the first block of an upgrade all the way to the last block of it before the next one. And throughout the auction people bid for what the name of the upgrade will be. And this kind of a dynamic auction so throughout the auction whatever the highest bid says the name is is what we refer to the upgrade as for that point of time. And obviously whenever someone outbids that bid then you refund the previous person, update the name and that's it. And there's a couple things that are important here. The first is that you don't want to have like a high minimum bid because it's premium namespace you're selling you want to make sure that people value it accordingly. And you also want to have large increments between the bids because you don't want people to spam the network while they're making bids for these names. So I had a proposal for 100 each. And this would obviously be a bit complicated on the client side because if they need to change the name all the time that's not ideal. So we could just use version numbers in the clients and use a marketing name that we use sort of in blog posts and what not. Kind of like Android does where all the major releases have both a marketing name and a version number. And so on the upgrade block whatever the highest bid says the name is gets finalized on chain and that's how we refer to the upgrade going forward in time. And what do you actually fund here? So I think we should do these funds and try to spend them on initiatives that have a high likelihood of improving the Ethereum network today. This means things like new thinking and discovery protocols some better testing some each one point X initiatives like state rent some coordination across the clients or even some research ideas like off chain storage. And again it's important to note that we should try to optimize to have a large set of initiatives so have fairly small amounts that are kind of proof of concept size that are spent fairly quickly. So in an ideal world you've spent almost all of the funds from one auction before starting the next one. But who gets to decide how we spend those funds? Purple hole for this is a three out of five multi-sig with the following parties. So you'd have someone who's there to represent the Ethereum Foundation who's not a client developer who's ready there to represent sort of the Ethereum brand and vision. You'd want to have two client developers ideally one or more not from the EF who are there to represent the core devs. And then you'd want also an independent protocol developer. So someone who's not affiliated with one of the bigger companies in the space. And finally someone to represent the broader community. So someone who's not part of the EF who's not a core developer but just represents the Ethereum community at large. Whether they're adopt developer and Ethereum cat herder or just some redhead or Twitter user who's very favorable towards Ethereum. And the people on these multi-sig would basically be able to rotate in and out on a per upgrade basis. So you're not signing up to this for life. This obviously implies you need a process to decide how you add or remove people from that multi-sig. And there's a couple constraints on the people in that multi-sig. Specifically that you don't want them to be able to get grants from the auction if they're part of the multi-sig. And even farther than that you probably don't want anyone from the organizations to apply for a grant if they control the keys to the funds. So for example if Beisu which is the team that I'm on was part of the multi-sig for Berlin which is the next upgrade after Istanbul. Then no one from Pegasus which is the company I work for should be able to apply for a grant from funds raised during that auction. And so one interesting question here is like what do you actually name the hard fork? So I have a couple proposals for what would be okay or not okay for names. Obviously this is something you'd want to prove by the community and you'd want to discuss. And more specifically you probably want to have a process where at least one person on a multi-sig has to approve of a name for a bit to be valid. So some couple ideas of what's okay just like some generic words. You don't want bad stuff, no offensive stuff and probably just like not anything confusing. So no previous upgrade names, no other blockchain names so it would be kind of awkward if you had like the ETC Ethereum upgrade. And generally like something that you would be okay sponsoring DEF CON would probably be a good name there. And finally if you don't raise any money during this auction then we could just revert back to using DEF CON city names which is what we started doing in formerly past Istanbul. So that's what I had. I have like a minute left if anyone has a question. Okay thanks everybody. Hello everyone. This is Hooman Farahman, I'm with Gartner. So in this session I want to share with you some end user perspective you know that hopefully help with adoption. So we have basically service in thousands of inquiries per year you know that relates to blockchain and pretty much half of them deals with you know selecting a blockchain platform. In many cases we'll see there's still a lot of confusion that what a blockchain platform is or is not. And that really play into the adoption and the ease of you know evaluating a platform. So there are many different definitions you know that we find out you know unfortunately some of them really doesn't make sense. You have to spend a lot of time you know for companies to first of all define a blockchain platform what it constitutes and take the next step to start comparing the platform which is out there and select something that works for them. So from what we have seen obviously Ethereum and Hyperledger fabric are the most popular one but I have to say that there is no loyalty to any of these platforms because still most of the organizations are testing you know and going through proof of concepts or some sort of limited pilot. So any decision that they make is not really a strategic one so in a couple of years or one year you know they may switch to another platform. So what we thought you know it may help is to start establishing a functional framework for blockchain platforms you know that helps with organizations to do an Apple to Apple comparison of different frameworks or platforms out there. Which there are hundreds of them. They initially come to us and say okay why don't you as a gardener go create a magic quadrant you know for all of these platforms. The challenge is that there are so many of them out there so and then they are changing too fast in terms of you know all the improvements that happen so it's kind of work in progress. So that's not possible. So what we did instead we created this framework that pretty much covers all the key functional modules from smart contracts, node management, the core blockchain transactions infrastructure and more and more the ecosystem management aspect of blockchain solution. So basically the idea is that this is not obviously perfect you know we are going to improve it over time but the idea is that first of all they get an understanding what a platform is and then they start asking the right questions. So for every of these functional modules we define you know what it is and then we introduce some questions that they should ask. So if you add them up it's about 142 questions you know that pretty much covers you know all the key important you know features that you may expect from a platform. Some of them may be applicable or not applicable depending to the use case that they have. And that will give them hopefully an understanding that for example what's the difference if they go with let's say Ethereum versus Hedera versus Fabric or them and some of the differences you know will come up in as part of that process you know. But the story doesn't change doesn't end there. What we have to deal with you know there's a lot of debates around public versus you know enterprise we see those are the two key patterns in terms of the design of these platforms. We see sometimes people try to differentiate these platforms in a much more granular way. But a lot of those differences we consider them as configurable features that over time they morph into the same platform that we have. And even between public and enterprise we'll see the lines will start lowering over time. So for example what's happening with Ethereum 2.0 we envision you know an environment that you can define a shard. You fix the validators for that those shards and eventually use some sort of gateway you know to interact with beacon chains. So while you are isolating your shard and chain you have the opportunity to connect to a public type of you know platform. So that's something that we try to convey to this organization. Not to too much you know stuck with having a shared ledger looking at the bigger picture of the platform like the crypto economics you know. Embedded native you know token you know that that's established in the platform that the coordination and consensus you know protocol the importance of them to make their choice future proof over time. But in addition to that we think the organizations need to also look at areas beyond just having the pure blockchain platform and that's you know things like decentralized web. At Gartner we believe that in the vision of decentralized web I think it's a key element of supporting digital ecosystems moving forward. So without having that fabric you know to do a trans verification between all sort of entities that having that vision of digitalization in ecosystem was almost impossible. So so decentralized web is coming and then from a platform perspective if the platform has a limited vision it cannot support decentralized web. So that's another layer that needs to be factored as part of the decision. So and even we push it further in terms of long term planning like 10 years 15 years down the road this concept of worldwide ledger you know that we are going to have any kind of a muted version of worldwide web that basically connect all these ledgers together you know with new type of identification methods new type of you know objects new type of protocols that we try to convey. And the whole idea is to help the organizations to understand you know where are we going with all of these technologies sometimes you know as developers we may focus too much on the bits and bytes you know and miss on the bigger picture which is important for them you know to build a case to adopt this type of technology. So so that's the idea you know as some kind of you know hopefully pointers you know as you want building you know all these great systems you know to convey it in a way that they can relate to and adopt it over time. That's it. Thank you. Hi everyone and welcome to Japan. My name is Yunosuke Nagayama. I'm master student at Tokyo Institute of Technology. Today I would like to talk about a network simulator called Shinbrook. Network is one of the important thing for us. So blockchain is based on P2P network so it's necessary to consider communication within the network. For example we want to improve the blockchain throughput. You will increase the block size and the number of blocks generated per second. But however this increases the block propagation delay and shorten the block generation time. So then it's it becomes difficult to synchronize blockchain in network and it's triggered the chain folks. So like this network communication is a cause of security degradation on blockchain. So we researched the improving the method for improving the blockchain networks. But it's difficult to experiment with real networks. So we developed a blockchain network simulator and we call it Shinbrook. Shinbrook simulate blockchain protocols and block propagation. By default blockchain using proof of work and longest rule on random networks. But if you want to test your new idea you can design the node behavior, network topology and network configuration to fit your ideas. And you can get the various data from Shinbrook. This data can be used for network measurement and attack analysis and so on. And this simulator was used for some experiment about the new neighbor selection algorithm and measuring the effect of the networks. So and now Shinbrook supports Bitcoin, Litecoin and Dogecoin. And we are developing for Ethereum support. But there are many Ethereum projects such as Casper, Prisma. So this time I simulated Ghost on Shinbrook as a sample experiment. Ghost is a block selection protocol. The current Ethereum protocol selects the longest chain as main chain. But instead Ghost selects the heaviest chain. Heaviest chain means subtree with the most blocks. So I try to measure the effect of Ghost protocol against selfish mining. This is the interim result. The left shows the ratio of the attackers' blocks in main chain corresponding to the attackers' mining power. This shows how much mining power is needed for selfish mining. And right shows the average length of the chain released by the attacker. This is related to the safe number of confirmation. This in both results shows the Ghost is better than the longest through. But it's not as much as I expected. This is probably because Ethereum has not so much focus. So I think if Ghost is more efficient with the more focused blockchain. So as this experiment, Shinbrook will help you to evaluate some Ethereum protocols. Please try Shinbrook and give us feedback. If you are interested in the Shinbrook, you can get more information and code on our website or GitHub. Thank you for listening. Please enjoy DevCon and Osaka.