ETHReport/data/archives/interviews.js

const InterviewsData = {
    '0': {
        'Name': 'Fabio Berger + Remco Bloemen',
        'How do you handle smart contract verification and security?': 'Code audits before deployment\nWant to add a formal verification tool to our deployment tool.\nBy analyzing the code, you can find patterns.\nI manually did an audit in v0 of 0x:\nMake sure all functions have a “Read -> Write -> External Call” pattern, so you don’t have any race conditions.',
        'Other bounties?': 'Rest of the bounties from Remco\nState-watching –– built-in diff’ing of state trees\nShould be implemented in the Ethereum clients – Geth and Rust.\nThey want this feature for OrderWatcher.\nEIP process is suboptimal:\nLacks in consensus-building. There’s vocal people who don’t have good ideas; there’s a lot of noise.\nTo improve: committee-based approach (reputable stakeholders from reputable projects who get together?).\nProblems are getting solved at the wrong abstraction level.\nE.g. NFT standards.\nNeufund was largest Solidity project before –– tokenized equity.\nYou want a EuroToken. You don’t want your company valuated in Ether.\nWhat if blockchain forks; which token is actually tied to the company?\nBounty approach gives many different styles within the codebase.\nThis is a problem; e.g. OpenSSL codebase after Masters / PhDs.',
        'Who are you and what are you working on?': '0x - Decentralized exchange protocol. It is a set of smart contracts that handle standard transactions in an order format.\nThe key advantage here is that these smart contracts leads to shared liquidity\nWe also achieve increased security and network liquidity through our architecture.\nWe launched the network in August 2017.\nIt works, but is V1. We are working on V2 which helps people build hybrid stations, supports new token standards, and makes the contract more gas efficient.\nV1 only allows humans to create orders; V2 will allow new smart contract to create orders. This is HUGE.\nNotes:\nWe’re building the protocol; designing the standard; building dev tools for anyone to build a decentralized exchange.\nOrders may become invalid for any reason:\nOrder being filled\nGriefing attacks\nWe’ve now built an OrderWatcher that keeps relayers updated on the state of orders.\nWe’re using contract Events as a proxy for state changes.\nCan do a diff between state trees and between block headers.\nWe also have a set of smart contracts to handle settlement;\nEveryone who wants to trade is setting allowances on a smart contract.\nWe want upgradability.',
        'What are the tools/libraries/frameworks you use?': 'EthereumJS / truffle hardwallet provider / Typedoc (to generate documentation) /\nWe don’t use Truffle anymore\nNot reliable – can have race conditions;\nArtifacts don’t allow you to have versions of the contract on different networks\nYou don’t run into this stuff if you’re just building a “hello world”\nOverwriting parts of the contracts;\nWe rolled our own. It’s open-source but not documented. We have other things that are keeping us busy.\nThe problem is that Truffle has too much functionality –– we would like to see more of a Unix philosophy.\nCannot support different versions of Solidity.\nVersion management doesn’t exist.\nEthPM –– doesn’t have versioning either? It’s going through a big refactor, so we held off. We need the NPM package manager.\nWe have built a lot of developer tools to interface with the smart contracts ourselves.\nWe have also built own deployer and migration tool, as truffle’s did not suit our needs.',
        'What are your biggest frustrations?': 'Getting a simple experimental environment up is hard\nRemix is there; but it’s not enough.\nTracing and profiling is not existent.\nRemix does it, but can’t do it locally.\n“Code coverage” tool exists but inserts console.logs in\nAdding up gas costs per line of code.\nNeed to do profiling, because gas costs depend on inputs.\nSolidity language itself:\nCrashed the Solidity compiler twice today.\nE.g. AbiEncoderV2 is pretty new and hard to understand/use.\nThe code that it produces is inefficient.\nThere is a stark stack limit in solidity\nAll the variables are locally scoped.\nUn-intuitive as it is a curly braced language.\nThe lifecycle hook value_of is within a function.\nCan only access top 16 slack slots. Including input and output.\nWe need to implement a graph coloring register allocator – to find out what the lifetime of the variables is.\n“This stack slot was used in the first half –– the second half you can use”\nOr implement register splitting.\nFunction inlining is frustrating sometimes:\nE.g. SafeMath –– turns every operator into function call – which is a huge gas sink.\nHow Solidity optimizes could be improved:\nIt focuses on the code size (which makes sense since it’s minimizing the state tree); but sometimes you need to optimize size of tx gas (e.g. 0x needs optimized fillOrder call)\nABI doesn’t implement introspection\nEIP 165\nE.g. “does this contract implement ERC20, or ERC223?”\nSolidity should have this in-built.\nShould be built into the API spec and compiler.\nInheritance:\nInterface or abstract contract – e.g. Solidity automatically creates getters for state functions –– collides with\nContract which implements an interface – public or external for abstract functions – they collide\nERCs – there is not a formal way to describe the interface for contracts.\nHave a standard repo –– this will lead to a canonical ABI definition –– can have semantic rules around this. Could run some specific unit tests against',
        'How do you handle testing?': 'Testrpc has gotten better ––\nIncreases the speed at which you can dev.\nBlockstream is really cool. Written by Mica (from Augur?), under the EthereumJS lib.\nGood dealing with block re-orgs and changes in state.\nContinuous Integration:\nDoesn’t really work for smart contracts.\nWe just use testrpc.\nNeufund was different than 0x:\nNeufund was a trustee for tokens –– it was centralized by definition.\nThis made it simpler: I could create “open-ended” contracts –– a switch statement, that the default would send to another proxy contract.\nBut wouldn’t be able to do this with 0x –– e.g. if we wanted to add Shnorr signatures –– because it’s a governance / security issues.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '1': {
        'Name': 'Leo Logvinov',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'There is a limit on local variable numbers (have a limit of 16, which influences how you write the code).\nSolidity doesn’t push variables down the stack, so you can’t go more than 16 deep. This is an implementation detail in current compiler that needs to be improved.\nABIv2 - experimental feature for half a year or so - return structures and bus structures as parameters. 0x are planning to use it to make their code easier to audit especially.\nC++ devs needed',
        'Who are you and what are you working on?': 'Started in blockchain 2 years ago in Berlin, working on Ethereum devtools, building solidity plugin for IntelliJ, built by him and an Australian.\nWorking on truffle, did some PRs, improving speed, usability, error handling.\nStarted working on 0x, primary role: devtools team.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Event watching - unreliable, no support for backfills etc.\nBuild tool for statically typed contract (ABI gen that generates contracts), build out the statically typed libraries\nNegative experience with web3js team - unresponsive.\nFrustrated with truffle because it is hard to contribute with so many packages these days.\nHard to debug and understand it all - so needed a smaller truffle for the specific use cases.\nNeed to standardise their artifact format (currently in talks about it).\nSolidity coverage tool: built at hackathon (at least the profiler which is not super useful), standardise on artifacts format so that it works across tools.\nWhich line of solidity is covered by tests?\nEIP712 - standardised signing for structured data, also helped finalise 721 at ETHDenver.\nSolidity plugin for IntelliJ IDE\nOne did not exist at the time. Did not have too much stuff in it really: simple formatting, definitions, highlighting. Not “a super interesting” project, but has 36 000 users (some duplicates).\nVMs\nBeen wanting to speed up tests recently. Bottleneck is code execution in Ganache VM (90%). We want to get down to 1-10s test runs.\nGAS PRICES ARE NOT THE SAME!!!! Arghhhhh!\nWe need JIT compilation in more performant language (currently just executed in JS).\nProject called EthJIT VM, transpiles to LLL, then optimizes contract so that it is precompiled and then runs much faster.\nWould be great to see the integrated in ganache (snapshots and time travel make this a nice tool than geth to use currently).\nEven better to have pluggable VMs, have spoken to the Foundation about this too.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'Prettier type plugin for solidity. I don’t have time to write it but Prettier has a good API.',
        'Other domain specific questions?': 'What has your experience been like working on EIPS?\nWorking on EIP 712 - signing structured and typed data\nQuite hard with monetary prospects and no established legislation process - need better ways of governing and enforcing the process.\nReally helped to have everyone in one room at ETHDenver and align on angles of attack.\nRoom at ETHDenver from commenting on a thread in GH. Started unstructured and moved into structured discussion by defining the interface, which helped identify all the different parties’ motivations. This revealed some inertia on some teams’ behalf, which was interesting to see.\nLot of discussions about metadata (of tokens, which is also important for other parts of tokens)\nGH PRs are one single wall of text and the comments need to be better moderated, especially for trolls or tangential discussions/ideas (especially tangential ideas need to be collapsed).\nCreators need to moderate/create a TL;DR section to help people better and more easily grasp what they are working on.\nSolidity code coverage - how does that work?\nBefore each line calling eval, and modifying Eth and ganache code to read the events, much below the current block gas limit and working through everything that comes through.\nTake debug transaction with list of opcodes. Also have the source maps, which map back from opcodes to lines of solidity code, and can use that the work backwards from opcodes to understand exactly which line used how much gas.\nHow do you get the trace after each tx?\nWe wrote our own provider, whenever call to eth_sendTransaction gone through provider it sends it and then gets the trace.\nCalls don’t have traces though, so need to do a snapshot and then send the call as a tx, which gives you the trace back and then you can look at what happened in the call.\nDid look at other tools, but felt the performance and reliability of those tools just kinda sucked.\nCan you tell us more about Event Watching?\nLacking good open source project[a]\nPeople don’t have stateful nodes, you need to handle events client side\nEthereum-js blockstream enables us to use stateless nodes after installing all filters. Still not a part of web3.\nWorking on something called order-watcher: track when the order becomes invalid. Which happens when the user manipulates things. You can validate reactively by watching for events, but you want to actually watch balance changes and events are just an imperfect proxy for this.\nPeople can mint and burn tokens and change balance without emitting events.\nWant to track changes in balances, not events. balanceOf() is view function that returns the balance, so we want to track the result of calling that.\nMight be inefficient to look at that directly, or we can register callbacks and recompute only when the state used by that function changes.\nBut how do we know when state changes?\nCannot rely on solidity, but can run function, get trace, see which storage slots the function is reading, and then you for sure know that this function will only change its value when one of those storage slots changes.\nUse Patricia tries somehow to watch these storage slots and state changes - allow you to watch efficiently changes on view and pure functions.\nCheck out EIP 781: https://github.com/ethereum/EIPs/issues/781\nCan you tell us more about ABI gen for statically typed contracts?\nContracts need to be checked at compile times to ensure parameters etc (strong instead of number or something like that) and being statically typed is much easier to check this.\nInspired by geth tooling, and there are also some JS ones (salt-size etc) but were all very opinionated and made all sorts of assumptions about how you wanted to use your contracts.\nWith 0x tool: Consensys is using it, Sybil (journalism tools, also with typescript contracts).\nUsing ethers.js for backend of contracts due to issues with web3 versions (classic).\nBest ideas to have in a debugger?\nNot writing solidity actively at the moment and I haven’t used one yet because it is such a high 
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '2': {
        'Name': 'Axel Ericsson',
        'How do you handle smart contract verification and security?': 'Human thinking and auditing.\nWill find some external team to do a professional audit.',
        'Other bounties?': 'Breaking out a javascript library for web pages that are accepting payments, which allows you to accept any kind of wallet mechanisms: Ledger, Metamask, Priv key, encrypted keystore, etc.\nSame thing needs to exist for desktop software. Need a simple desktop wallet that accepts any kind of access to payments.',
        'Who are you and what are you working on?': 'I have built 1Protocol\nIt lets smart contracts sign up as miners on different proof of stake protocols\nLet users provide the contract with the stake\nIt’s like a mining pool, but for staking\nThree things\nInterface for signing signatures (like MEW) and sending tokens to mediators\nBuilding actual contracts that accept tokens and are signed up in Raiden as a mediator\nActually running the mediating machine on Raiden.\nEventually, anyone can send tokens and anyone can run the machine\nFor this, simply writing software around the Raiden node client. Raiden has published a python client. When you run it, it exposes an API on your computer, and 1Protocol is writing software that interacts with that API.',
        'What are the tools/libraries/frameworks you use?': 'Just web3JS and the python raiden client',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Truffle suite. Before that, built our own unit testing system.',
        'What tools don’t exist at the moment?': 'There is no tooling or anything related to state channels that is trusted yet.\nNeed the MEW of state channels.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Solidity is changing so quickly that, as an example,\nchanges to visibility modifiers (public / private etc.) has gone through a view iterations.\nIt would be great if there was a resource that combined solidity read the docs with the github releases[a][b]\nNeeding to resolve problems like how to setup web3, talk to contracts, remote vs constant transactions. Lots of re-implementing solutions.',
        'What are you most excited about in the short term?': 'Raiden is the golden egg in the space. The experience of actually using Ethereum will improve a ton.\n“Counterfactual” team building some general purpose state channels.\nLess bullish on actual applications on Ethereum right now.',
        'Was anything easier than expected?': 'Writing smart contracts is surprisingly neat. Not actually as hard as it seems. You can have a mental model of all the moving pieces in your head, which is actually harder with other kinds of software.',
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '3': {
        'Name': 'Mike Goldin',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Pretty cool to have more languages for the EVM. Solidity is only reliable one. Yoichi’s Bamboo is moving along.',
        'Who are you and what are you working on?': 'Software developer at Consensys\nKnown for Token Curated Registries 1.0. Works on team turning TCR’s into product which in turn informs the engineering/design. We fully intend the projects to succeed so we can incorporate feedback. It’s all still experimental, though.\nTCR came from AdChain. Deployed to Ethereum mainnet on April 24th. Useful for data on how people interact when there’s actual money at stake. New type of TCR where token supply inflates after every vote.\nAdchain allows publishers and suppliers to find each other on a p2p.\nBy using TCRs to curate who may participate, cut out middlemen as well as bad actors.\nFocus is on onboarding.',
        'What are the tools/libraries/frameworks you use?': 'Truffle, useful as a testing framework.\nSolidity linter, Sol Lint. Not super good, but alright. Eventually, I want an Airbnb javascript plugin for ES Lint.\nGanache Test-RPC\nEth.js sometimes',
        'What are your biggest frustrations?': 'Truffle’s debugger is a bit disappointing. Works well for simple pattern, doesn’t support different types of contracts i.e. proxy pattern.\nNeed an Ethereum Package manager. Wishes packages were update. Should move from Ropsten to mainnet. Publishes and consumes to EthPM. Adoption is still low- EthPM.\nMade technical assumptions early on, problem could only be discovered when going into production. User data you get from running on a testnet. People’s behavior changes as you add real money.\nOffline simulations of incentive games with $10,000, offline IRL version.',
        'How do you handle testing?': 'Writes tests in Javascript\nSol Coverage tool\nWants 100% code, branch etc.\nGithub is part of testing workflow because of code reviews\nHow do you handle smart contract verification and security?\nAlso Josh Cassidy',
        'What tools don’t exist at the moment?': 'Fuzz Testing and formal verification desired.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Hardest part is learning to develop in a blockchain environment, not solidity. Learning the javascript versus learning the browser. You can learn the language formally but learning how to apply the language in the browser. Blockchain environment is very different from anything else.',
        'What are you most excited about in the short term?': 'Excited for Casper\nApplications implemented in Plasma, generalized state channels.',
        'Was anything easier than expected?': 'What’s really easy is programming money.\nOn blockchain, every individual has universal payments identifier.',
        'Who are the other people you think we should talk to?': 'Infura team, client development\nSpankchain - pretty aggressive on focus to',
        'What are the best educational resources?': 'Solidity Docs\nUses yellow paper gass lookup table\nNot sure',
        'Are there any other questions we should be asking?': null
    },
    '4': {
        'Name': 'Oleksii',
        'How do you handle smart contract verification and security?': 'We have written our own tools which tell us, for instance, that “this variable is never used.”\nAlso includes optimizations to improve gas usage –– e.g. read address value and store in memory before loop, then call into it.\nFor contract address, for state variables, etc.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Started working with smart contracts in early 2016.\nStarted by writing tests using Truffle for other people’s contracts.\nThen, started educating himself on Solidity, became a smart contract developer.\nWhat do you do at Ambisafe?\nDo custom development for clients.\nOur own products: e.g. webhooks for contract calls.\nScalable supernode solution – logic to make the node robust, etc\nPlatform to issue tokens. Fixed set of contracts, but for every new token, they deploy a new contract as a gateway.\nGateway token contract – implements specific logic of different tokens. Fees, etc.\n+ Toolkit for DevOps / deployment:\nJavascript functions to solve common problems, tx propagation issues, …\nTx propagation issues: sometimes your node gets a tx, but doesn’t propagate to any other ones. Mostly seen in Parity.\nDeployment scripts\nChecking that the gas that’s going to be spent; if enough gas is provided.\nScripts to collect info from the blockchain, doing sanity checks to make sure it’s all good before proceeding, then collecting data after, …\nCOULD THIS BE A BOUNTY TOOL?\nCloning of contracts.\nMost of their contracts don’t copy any code anymore.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Our original vision was to do everything – testing, deployment, etc - through Truffle.\nBut, in reality, we’ve only used for testing.\nFirst version of truffle was using the testrpc snapshots for reverting – good for unit testing.\nIn second, third versions this was removed.\nMost companies use truffle for testing, on testrpc.\nWe made our own helper to make snapshots and do reverts on testrpc before/after tests.\nNow, you can deploy the contracts from inside the tests; you’ll have a freshly deployed contract.\nTruffle’s designed to be used by a single project –– a fixed set of contracts that doesn’t change much.\nBut most of our projects have different platforms, so we end up deploying different versions of our contracts over and over again.\nWhen Ethereum started being regularly congested\nBuilt functions to overcome this – tool for: re-submitting transactions with higher gas prices when they don’t get accepted.\nPeople don’t track nonces correctly:\nTool for: figuring which nonces were skipped, and creating transactions for them.\nWe check for compiler errors + static warnings in Remix.\nI haven’t used automated tools like Securify.\nI just read the contract for as long as possible, so that I understand the contract as if I wrote it myself.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'What are other great tools you have used?\nEthercamp – a smart blockchain explorer:\nHeuristics while parsing and indexing the chain.\nHad a convenient interface to explore the storage of the contract; even without an ABI, the heuristics allowed you to see that e.g. “this key is this address”. And then showed this stuff in a human-readable way.\nThen, they kind of stopped their resources.\nMore details on you data collection & devops tools?\nFor it to be useful, it requires time for refactoring.\nIt’s usable right now, but code could be improved.\nMaking complex deployments possible.\nIt won’t be too complicated to build.\nTool for: pulling balances of some tokens of some addresses\nTool for: making airdrops cheaper to do. E.g. 20k addresses with batch deposits happening through a smart contract.\nLLL language?\nIf you’re using Solidity, you can’t have the maximum optimization in your contract.\nConvenient way to write contracts in Assembly?\nHe wrote bytecode by hand, for the contract they deployed a million times.\nHaving a better low-level language that compiles to bytecode.\nThe call trace in Ethereum?\nIt doesn’t currently provide you with any help.\nUsing 4byte.io, you have the ABI of all the functions in the trace.\nYou can build a human-readable layer above it, and see what’s going on.\nCan have a real stack trace for function calls between contracts, with what values.\nAction items?\nOleksii to outline needed features / requirements for smart deployment tool.\nUs: intro him to others interested in in collaborating on above & scoping out requirements.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '5': {
        'Name': 'Brett Sun',
        'How do you handle smart contract verification and security?': 'Human audits only right now.\nTrailofbits is really interesting, been wanting to play with Enchidna. These guys come from a traditional infosec background and it really shows, because their professionalism is on another level from anyone else we’ve been exposed to.\nA lot of the actual code can be checked fairly automatically, especially with the more hardcore tools now coming out. You can’t really automate some of the creative, game theoretic attacks, but there are people who are very good at this now.\nTried Oyente a while ago and did not have a good impression. It didn’t really provide that much and the things it could identify were pretty easy to spot anyway.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Working on Aragon entirely.\nThe end goal is to create a network between organisations that live on Ethereum (and potentially other platforms in the future).\nThis required a lot of foundational features.\nA network of organisations requires organisations in the first place! So we have been working for the last year to build these.\nWe are now switching gears to think about what a network between the orgs will really look like.\nWe build aragon_os: an OS for organizations. We tend to think about resources (i.e. people and money), and structure the OS according to well-known principles. Instead of people and money, normal OSes manage CPU and RAM etc.\nTwo key pieces to this sort of work:\nControlling money.\nControlling permissions.\nWe also provide a lot of UI components on top of the contracts that we are writing.\nThe entire goal of 0.5 (live on Rinkeby now) is to allow people to easily create and manage their own organisation, along with granular permission and financial management.\nShould be able to create their own application to live in their organisations: and this is where we imagine the network of organisations will emerge from.\nHooking up your own apps, and designing your own interfaces to handle certain complex behaviour',
        'What are the tools/libraries/frameworks you use?': 'Four categories:\nEVM and lower level stuff:\nA lot of our problems have been solved by solidity 0.5 pragma\nRevert with reason! Should be better for error logging.\nDynamically-sized parameters inside the EVM. We did not have an opcode before Byzantium that could have handled returndatasize with dynamically-sized stuff.\nWe play a lot with assembly and ABIEncoding has really bugged us before inside Solidity. So when, for eg, we want to stuff dynamic arrays with mock call data sent through delegatecalls. We have to do some funny business to properly encode them, and 0.5 exposes tooling to do this automatically.\nSmart contracts:\nNot a lot of great tools here yet, especially around testing. This seems to be a fairly obvious hole.\nNot a big fan of Truffle, even though everyone seems to use it. It is especially slow when compiling.\nSolc can be installed directly on most distros, and does stuff in less than 1s, whereas solcjs will take 20s, so why would you go for the latter?\nDapphub has their own set of nix-based tools that I haven’t tried yet, and really want to. But the barrier to understanding here if you don’t come from the right programming background is very high.\nWe use a bunch of standard libraries like Open Zeppelin, and the MiniMeToken and some other cool code that tends to fly around on GitHub or Reddit in the right places. However, this is a tricky place right now, because Package Management is unclear and no-one is yet sure if they want to use ETHPM.\nThere is a lot of people copy-paste contracts into their own repos, which isn’t great. It would be better to see them moved between repos with commit hashes and proper referencing.\nWe do this, as it is especially helpful for auditiability.\nDev tooling that allows people to easily build aragon applications:\nIt’s tough to develop Ethereum applications right because there are a lot of things you need to spin up yourself.\nDeploy a local chain, deploy your contracts onto it, and then only with that done can you start building a UI linked to that chain.\nNot too bad if you have just a few contracts, but with the way that Aragon has been designed (esp in term of flexibility) there are a lot of components that need to be deployed on chain before it all begins to work.\nENS on local chain, APM, base logic contracts, factories to extend the proxies on top of those basic contracts, and then only do we have a good chain state for people to hook up a UI against.\nThis produces a lot of friction, both internally and externally, so we have this goal to simplify it all.\nGanache has a snapshotting feature where it will dump the entire chain state (the whole patricia trie into a bunch of JSON files) that can then be used to start up your own chain from that state.\nHowever, when you tell Ganache to run from the snapshot, if you do anything on the chain, it overwrites everything.\nSo you actually need two snapshots and some patience to get things right.\nWe also need to deploy things onto IPFS, which adds another barrier for users wanting to get going with local development.\nSo, we have tried to build this command into aragon-cli, called “aragon run” that handles everything for you.\nBased on the brittleness of tooling though, it’s very difficult to make this reliable, and get it to error gracefully and debug why it isn’t working when it fails.\nUI:\nNot too much in terms of Ethereum-related tooling - a lot is just normal, front-end javascript.\nMajor frustration is web3.js. There are just so many things wrong with that package… “Every day is new adventure when using web3”.\nPretty much every time we have had to do something for a deadline, we have run into issue with it that have delayed us.\ni.e. in Buenos Aires, we wanted a mainnet launch for our Survey App, for which we need websockets and https.\nWe set Parity up with secure websockets on our own node and launched our UI and web3 just doesn’t connect to secure websockets. So what was the problem?\nTook some hours to play with all th
        'What are your biggest frustrations?': 'My biggest general frustration comes with the relative youth of the whole industry, which underlies a lot of our collective frustration, including both security and development.\nIt feels like we sometimes have our hands and feet tied when we are trying to make something. When you make a typical web app, there is a lot of freedom in tooling and the tooling is robust.\nYou can make changes easily, watch these changes propagate, feel productive, and get feedback immediately.\nThis is not the case on Ethereum - things that should take a day actually take a week or a month.\nEstimation of time is really difficult, but especially in Ethereum given how many unknown unknown there are.\nIt’s really easy to get started, but it gets harder and harder to maintain.\nNow that we have a lot of stuff built out, we now have to maintain it, and that decreases the rate at which we can ship new features as there is a lot of old architecture you need to deal with.\nFeels like we’re playing a lot more defense than offence. Was first introduced to this by Jon Choi: you should be proactively pursuing offense and limiting defense (i.e. innovation over optimization).\nAll of these tools that are “not quite robust” tend to waterfall a lot, which means we are consistently on the defense, even against the tools we’re using.\nNo teams are really at the level of engineering that we need to be at. It’s all shooting from the hip right now, which we fall into too because we want to ship things quickly.\nThere are no really great patterns or best practices or frameworks to follow just yet, or at least a shortage of them in the ecosystem.\nEvery year in traditional ecosystems, a new testing framework will come out, which is really great and I would love to see a similar situation beginning to happen in the Ethereum world.',
        'How do you handle testing?': 'In addition to the above we also use solidity-coverage, which can be super painful too. Not sure if the most recent version has fixed some of the issues, as we haven’t yet upgraded (we pin our contracts to an older version of solc for security reasons after they have been audited with a specific compiler version).\nAll of the tools are tightly coupled to the solc versions they use, and this becomes an issue in general for updating tools for coverage and testing. This should take 30 mins to set up, and yet, our CI is still broken today because solidity-coverage just does not want to work.',
        'What tools don’t exist at the moment?': 'A nice debugger! Please…\nMore infrastructure to easily set up your own node, and second layer tools on top of that to help cache data, because Dapps in 10 years are never going to work with just events...',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Google + Github is my go to.\nNot enough has been written on effective workflows for building decentralized products with new and largely untested tools. We need more developers writing about their experiences. Even if it is just a simple Tip & Tricks list or Awesome List.\nFor instance, I consider the Consensys Smart Contract Best Practices repo to be really helpful, especially for people coming in. Something like this would be great for general workflows:\nHow to debug transactions, for instance.',
        'Are there any other questions we should be asking?': null
    },
    '6': {
        'Name': 'Jorge Izquierdo',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Infura that is more decentralized. A full-node infrastructure[a].\nAn open-source explorer.',
        'Who are you and what are you working on?': 'Aragon - Decentralized Governance platform\nWe had a feeling that they had to go deeper into the stack to launch Aragon.\nWhat we’ve built:\nWe’ve built two different interpreters:\nLanguage for ACLs\nLanguage for tx descriptions, similar to Natspec.\nAllows you to do calls to smart contracts; but really basic stuff;\nBuilt generic framework for interacting with their contracts. Our dApp changes; needs to integrate with 3rd party apps without allowing dApp developer to touch the database.\nRuby on Rails abstraction on-top of the data layer.\nProblem here: we don’t have any servers, we are a real dApp. Every single user has to compute entire state of the dApp.\nBackend protocol / caching protocol / event-processing.\nUpgradability stack.\nTooling to update storage etc correctly.\nTrustless signer: help people understand their tx before sending the tx.\nWorking with metamask on this.\nOur own CLI tooling\nWe have a package manager – backend to our app store',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Tell us more about getting deep into the EVM?\nNatspec lets you evaluate functions within call – this is problematic security wise.\nIt’s not turing complete at this moment\nNo one describes what transactions are going to do; Radspec is the answer to this! Everyone use it, please.\nStandard around commenting exactly what a transaction does.\nDocumenting what the source code does\nSolidity puts a hash of the code, at the end of bytecode.\nThis process of automating the comments could be automated; pulls comments from Solidity source code, add them as comments for devs\nIntegrating dApps with blockchain?\nLocal caching in the browser; what are the block numbers; do a Reduce to see how an event impacts the state.\nProblem with the caching layer: the info not only comes from the Event, but data you get back from contract depends on the block number\nPerformance is an issue:\nAugur: ethereumjs-blockstream.\nLibrary-driven development & upgradability?\nIf Solidity changes how variables to storage blocks, if it changes this, there’ll be problems. They want to build a tool that does a sanity check that checks still works[b]\nTool to do a sanity check over the storage layout\nIf new contract uses different version of Solidity, could get that directly through proper use of interfaces.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '7': {
        'Name': 'Jack Peterson and Sparkle',
        'How do you handle smart contract verification and security?': 'Pay others to think about it - no process yet.  We write a bunch of units tests, and we are going to run things through Oyente (Formal Verification).\nBiggest problem - always has been - test thoroughly and comb through the code. Use static analysis tools. The biggest thing holding us back:\nMaybe better standards for writing this stuff (NASA)\nCreate linting rules?\nHave people working on project exhaustively review the code is the only way to do it right now. Certain classes of errors can be caught with unit tests, but we don’t catch everything.',
        'Other bounties?': null,
        'Who are you and what are you working on?': null,
        'What are the tools/libraries/frameworks you use?': 'Back-end: Visual Studio Code with docker images that run pythereum for unit tests.\nSolidity compiler - Solium linter everyday\nIntegration tests run against Geth/Parity nodes\nCustom libraries -- all their own RPC code.\nNo web3.js (ETH.js libraries are better)\nCan run locally or dockerized - have a CI pipeline (Travis)\nPush to Github and deploy to Rinkeby\nCustom deploy tools are a huge headache. Doing a full custom deploy is like launching a satellite into space. There is a huge chasm to cross and a lot of the stuff is non-obvious\nTruffle is used for this -- very challenging because it lacks deep modularity and customizability.\nFailed at random on different networks after working reliably against testrpc. It won’t tell you why and is deeply opaque. There is no error messaging and it is hard to use in general. The dependency of contracts gets very complicated (because logic is complicated).\nThere is definitely more work to get Truffle smooth for everyone\nActual contracts / delegate contracts -- build system is incredibly specific to their framework and difficult to adapt/customise.\nUse Geth / Parity\nUI -- react / redux.\nAugur node is typescript ..\nLots of small things -- middleware library called ethereumjs-blockstream.\nLibrary for generating keys and key files -- keythereum.\nKey management is tough -- self signing (so can leave unlocked Geth instance, which is not good either)',
        'What are your biggest frustrations?': 'Lack of a debugger - by far the biggest issue.\nNeed to print things from failing transactions and can’t do this\nRight now, we just attempt the transaction until it doesn’t fail. We are often unsure why things fail, just keep going until it doesn’t. What’s missing is break points and executing code from that. That will shorten feedback cycles.\nDevelopment environment is really bad right now…',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'Setting breakpoints in tests!\nSalesforce Development:  Public thing where you post your code to it and everybody works off of it (lots of bounties projects now up from Status Open Bounties to Gitcoin and bounties.network).\nHaving clean Dev Nth without 30 things to set up:\nReact project will need to talk to Geth / IPFS / local = lot of setup is irritating.\nIf a transaction fails, the logs don’t get written. This needs to be in the EVM\nHaving many slacks is a big problem. We should have 1 slack with all developers.\nDocumentation is also terrible.\nWhat documentation would you like to see?\nTooling / documentation / community takes like a decade to develop. (Check Kauri for a possible solution)\n“How does Geth estimate Gas” - need to ask a bunch of people and it’s not written anywhere.\nHow much gas does a particular operation cost? Is this written down anywhere?  (People point you to yellow paper, but it’s very hard to understand.)\nIssues are not addressed so well by the Ethereum Foundation. We’re talking about normal software development issues and sometimes the Foundation seems unfamiliar with best practices.',
        'Other domain specific questions?': 'Let’s talk specifically about UI issues / scaling?\n  Stabilisation of contracts: we need clearly defined API’s against contracts.\nWhen you change behaviours on a contract it has a multiplicative effect on the UI. One small change can have effect where you change 10 views. This lengthens dev cycles and having an API defined is important.\nIn general, it is hard to write business logic layer. Augur is writing a middleware node to overcome this.\nImpractical to fetch large amounts of data from blockchain - it’s too slow. It takes a minute and half to get data (how do you manage that experience in the UI?). Running a remote geth node - fetching data from logs + contracts is not fast either. This can be improved.\nHave an Augur node or SQL database -- pre-fetches and pre-processes Augur gnodes to make them available… But this also constitutes an annoying extra thing between ETH and client which can be slow / unusable.\nLookup mechanisms are primitive!\nSize limit on contracts is really annoying -- can’t deploy to Ropsten because of it. It took significant engineering to put something on testnet (had to 51% attack it to increase block size).\nGetting TestNet eth is hard ---  not a way to get a good amount of rinkeby (can only get a little bit from faucet -- don’t want people spamming it with transactions)\nReally intense test suites running against Ropsten (Raiden…)\nWould be great if we could easily spin up private chain to deal with that. Build a service to spin up private test nest that would have a certain amount of nodes.\nCurrently, this takes days of work -- what about standard service to do this?? People run these in different setting -- EC2 that is configured would be very useful..  Could store copies of Rinkeby and boot them up when people ask for them…  (Infura will evolve into this)\nWhat would be the hardest part of teaching your Mom how to use a dapp?\nHow ETH account is different than an account on a regular website.\nFew ways to login to Augur -- can create an account on the website, but you have to keep track of it (like creating an account on the website).\nAirbit will create accounts for Augur that will behave like regular website.\nHad 2 bounties -- posted on Bounties Network -- and it worked\nLinter rules -- portable debugger\nUnit tests die and you attach a debugger to it -- nobody supports break points.',
        'What was the hardest part about learning to develop with Ethereum?': 'What steps do I need to follow to write these apps?  Isn’t anywhere here that helps you that much.\nDevelopment cycle for Augur has been roughly three years - and mostly not development stuff. We had first working version of Augur on testnet after 4 months (been iterating since then).\nIt worked, but it didn’t scale and we found security problems. One can’t release software with bugs in it. So this weird balance needs to be kept as we cannot actually “move fast and break things”\nStart with simple system and iterate on it.\nOnly way to do it is to do it on testnet first!  There, you inevitably encounter edge cases or developers notice something.',
        'What are you most excited about in the short term?': 'Raiden is coming shortly and will be very cool.\nLooking forward to Proof of Steak.\nUPort going live will be cool on Rinkeby. Is now integrated with Augur.\nNothing blocking Augur yet.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '8': {
        'Name': 'Joey Krug',
        'How do you handle smart contract verification and security?': 'Yeah, encourage everyone to use auditors. Lots of multisig tools out there that don’t have CI builtin. Oyente, Mythril, but one problem is that no one else really uses them. Lots of bugs they found.\nTools are very well optimized to run for one smart contract. But not to run on suites of smart contracts. But if you fast forward a few years this will be relevant.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Co-Chief Investment Officer at Pantera Capital and Co-Founder @ Augur.',
        'What are the tools/libraries/frameworks you use?': 'At Augur, stack is different as it’s a bit older.\nIDE: if you’re doing something simple you can use something like Remix. Remix has all the kind of stuff you need, automatic static analysis to detect bugs and very visual and easy to run.\nMore than 5-10 smart contracts, beyond ERC20 and ERC-721, now Remix will fall apart\nUI is a big clunky as you add more contracts\nIt’s hard to write a complicated test suite with continuous integration. Instead use Sublime with terminal or EMACS and VIM. Augur primarily uses a Visual Studio Code syntax highlighting.',
        'What are your biggest frustrations?': 'At the end of the day, it all comes down to the tech side. Biggest frustrations are that it’s hard to write scalable software on something on Ethereum. State of scalability is very nascent. Product he’s advising for payments, they look at state channels. But when you try to use MVP’s, it doesn’t work. But it’s really a comment on scalability not on the individual company. L4 working on generalizable state channels, excited about that.\nFrom a business standpoint, you want to build on Ethereum. People come to them and say they want to build EOS. Reason Ethereum doesn’t scale is that they’re trying to scale and not make a huge compromise. But there isn’t a lot of marketing. We want to articulate why Ethereum is a good platform to build, not just look at TPS.\nWould be cool if Ethereum Foundation put some posts on the blog for what’s in the works for everything.',
        'How do you handle testing?': 'Run against pyethereum. Test suite is written in Python. As an investor, most companies are in JS environment with Truffle. Like Python a bit more. Truffle complaints are it has a lot of quirks. Default instructions for setting up tests in Truffle you get a weird nested stack of tests.\nUX blockflow IDEO for Truffle, doesn’t need to be rewritten but needs to be improved.',
        'What tools don’t exist at the moment?': 'My answers changed over a time, 1 year ago it was static analysis. These tools exist now, but they need to be improved. The tools themselves don’t have test suites, for example and they need more firepower in general.\nFrom an investor standpoint these dev tools need to be improved.',
        'Other domain specific questions?': 'Would be useful if the Ethereum project could add more firepower to underlying network. Propagating a block and you have a certain amount of time to do it otherwise you could fork;. More low hanging fruit at the network level.\nA really simple idea is when blocks are propagated, just propagate the tx ordering. Then have clients gossip for missing tx’s. A concrete example is for Bitcoin Bip152. Could this work Ethereum? Make something like this for Ethereum. Implement in Geth in Parity',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'In the short term, he’s most excited about Maker DAO in the wild. A good stable coin.\nScalability for mid-to-long term focus. 4 years ago it was just discussing what the block size is, but that’s an improvement for just one time. Interested in sharding implementations.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Back then documentation was very sparse, blogs posts or Reddit posts written by Vitalik or other people. Try stuff and see what works, back then everything was on Skype. Now it’s quite a bit easier, Solidity docs are much better.\nWhat about for people getting into the space now? Google + original docs + Stack Overflow. If you’re stuck go to one of the Gitter channel and ask the question.',
        'Are there any other questions we should be asking?': null
    },
    '9': {
        'Name': 'Mark Beylin',
        'How do you handle smart contract verification and security?': 'Consensys diligence is an auditing team available for their teams.\nArgus (Berkeley audits chain)\nDidn’t find anything in our latest audit\nDiligence at Consensys later found a re-entrancy vulnerability\nOyente also missed the re-entrancy bug(!!)\nHaving bug bounties in general is a good standard',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Creator of the Bounties Network. Bounties on any task in any Ethereum token. Frontend that relies on Infura and IPFS.\nInfura doesn’t let you listen for events. They have websocket capabilities that may be in beta right now.\nUsers use metamask for calls and transactions on it\nI am the only solidity developer throughout its life.',
        'What are the tools/libraries/frameworks you use?': 'I know and use the solium linter.\nUse truffle, testrpc. I love Remix.\nUse Remix for deployment. Feels like I can trust remix to work as it’s meant to.\nWeb3JS, BigNumber, site is built on React.\nIPFS JS library.\nBlockies react library.',
        'What are your biggest frustrations?': 'Not being able to upgrade my contracts easily.\nBetter ability to return data, specifically variable length data. Arrays of strings. Mappings of strings to data, etc.\nAbility to just dump the whole state would be great.\nGas limit:\nGas costs are high. Gas limit was a problem very briefly when trying to deploy a contract. But if your contract is running into the gas limit, it’s probably too big.\nOff-chain computation:\nNo. Smart contract doesn’t care about off chain. Stores stuff on IPFS and just stores the hash on-chain.\nState Channels:\nOnly read about them and researched how they could be used.',
        'How do you handle testing?': 'Mocha tests using Truffle and testrpc.\nAlso use Rinkeby for when deploying staging versions.',
        'What tools don’t exist at the moment?': 'Better querying possibilities on the state of contracts. Better indexing to do this. Even something that will just shoot results into a SQL table.\nA good wiki that is endorsed by the foundation but curated by the community.\nE.g. “How to do X”\nE.g. “What is X”\nPeople don’t know what they don’t know',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Didn’t understand the stack. People don’t understand what’s in between dapp and the blockchain.\nReally solid boilerplates would be very helpful for new people to see how easy it could be.',
        'What are you most excited about in the short term?': 'Sharding. That’s all I want.\nuPort is getting ready for mainnet, feeling excited about that.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Joseph Vander (learning the be a solidity developer right now)\nKevin Owocki from gitcoin',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Curious to know about developer incentives. Assuming you can make the same amount of money, would you prefer to build your own project or work on other people’s more established projects?\nE.g. bounties for Augur vs building your own little dapp'
    },
    '10': {
        'Name': 'Aidan Hyman',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Working with parity and geth and parity-bridge. Optimising the EVM for bespoke needs - could be for clients, for enterprises. Lower level focus.\nCreate tools and mechanisms for people to utilise the tech as easily as possible.\nCollaborating with Aion & Shyft on potential implementation of a bridge.\nBoth on top of parity-bridge, which has some limitations:\nMade only to work with POA.\nData availability for token information, following delegate_calls and not events.\nSuggest work with Jay Rush and maybe add them into the team!!',
        'What are the tools/libraries/frameworks you use?': 'Truffle\nLack of modularity is the biggest problem (across all tools listed below). Building on top of, rather than within, the EVM you need to update the toolset you’re using and this becomes really difficult with the current tools.\nIf you implement some different opcodes in solidity, you need to take them all the way up. Open source is great, but it needs to be easy to fork and re-implement it easily in order for it to be really powerful.\nTalk to person who had to modularise Truffle internally (not just testing, but also the lack of modularity - if you want to change something and still talk to others in the space, the best solution is often to rewrite the whole tool yourself, which is less than ideal). Aidan to send intro to David about this.\nParity and Geth\nAlso speak with David and Greg.\nUse Parity due to responsiveness from the community and how good they are at answering questions!!! Great community - so NB!! Aidan’s biggest asset is his network of core community members, which really matters in decentralized communities - open channels of communication.\nRust is a more obscure language and people lack experience, hence geth is somewhat easier to use and troubleshoot.\nGeth has a bigger community, but the actual people developing the client aren’t as readily available as Parity.\nMetaMask for frontend development\nWere tasked with making MM work for client and had to rebuild a lot of the stuff. Will also send an intro to the dev who handled. Greg is his name.\nMythril\nHuge frustrations with this tool. Getting it running is a pain in the ass.\nIf it could be applied at the stack layer and not the smart contract layer. Build something like Mythril for an EVM implementation, trace things up the stack cleanly, add/remove opcodes, make new instructions. A stack explorer so to speak.\nCould spawn so many things because we could understand the stack in a better way and grab a lot more logic. Pity to see focus on higher level tools, which has become somewhat of a hindrance. Why hyperledger went out and did it themselves (not just the licensing issues).\nEducational tool for stupid web devs like me to learn about how opcodes actually work and are composed in the EVM.\nRegular rust and node related stuff (also some go stuff).\nAre there tools from these arenas that don’t exist in Ethereum which would be really cool?\nWe need to make these tools more closely aligned with the chain itself. With WASM coming online, this is already happening and we just need to be ready - i.e. teach everyone WASM.\nThe end if here for really high-level development with WASM. What this will mean for the community and internet in general has yet to be discussed completely.\nTry to use ethers.js as much as possible as opposed to web3\nThe person developing these tools (Richard) is totally accessible, responds to issues immediately (faster than a bot!!) - he is so collaborative and wants to make sure everyone is using the best tools possible, and this all makes such a difference.\nPolymath people doing off-chain signing, which you couldn’t do at the time and 1 of the methods didn’t have a response variable they needed, and by the next morning it was updated. Tight feedback loops make it so much better to use tools.\nYou can create your own wallet in 4 LOC in your terminal - again the language and syntax is so much easier for a non-dev that this solution ought to win in the long time. Very relatable and understandable code base.\nGave solidity and parity/EVM workshops:\nEVM workshop: took instructions, showed how it would be passed onto stack, where things go, how it gets passed on to memory. Questions were so relevant and knowledgeable.\nWhereas in the solidity workshop, the questions were much more absurd and irrelevant. Talking about the stack, people from a dev background get it. It just makes sense. Take away: if we want devs who have been developing for 20 years, we need to actually show them how the stack works.\nThis is a community-wide failure that we need to fo
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Talk with Stu, who handles all the testing stuff.\nUsed to do what Mythril does: visualize the contracts as it does now, so once it is set up, it is very cool for us to use.\nSuch a focus on formal verification in Solidity (but who even knows if it really matters?).\nNot doing fuzz testing for instance, and it seems like a lot of these requests are based on assumptions that have not been proven.\nNo-one knows what the optimal testing framework is, so more default templates in general that allow people to use what they need to use across different projects.\nAgain, modularity is what matters most.\nBoth unit and functional test as necessary. Unit testing seems more standard. Mocha and chai within truffle for the most part.\nEthereum-js VM has really bad testing around it and could be really usefully improved. We need some kind of local implementation to do testing on! Write another test suite as a bounty here.',
        'What tools don’t exist at the moment?': 'Mythril for the EVM stack. Rewrite a complete stack visualizer for the whole EVM. Add opcodes to the stack and see how it looks programatically and logically would be awesome.\nEven an overhauled IDE that is actually Integrated. Again, rewritten from scratch with a focus on modularity would be really nice to see. Even just clearing your cache properly and the way it physically looks is not good enough.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Two of our most exciting projects:\nShift - decentralized KYC/AML platform.\nBunz - a hyper-localized bartering solution. Started as FB group, grew to 60 000 users all bartering locally in Toronto. The people weren’t just bartering anymore, but using gift cards, subway tokens, beer bottles, anything that could be converted into transactable good. Crypto can be the main medium. Currently have 200 000 users on the app and website and over 1 000 000 items available.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Honestly just readthedocs, gitter channels and searching through GH issues.\nMoved from slack and gitter, to riot and gitter, and also ethereum stackoverflow.\nIf there is an issue, go to those repos as it is so unlikely that you are the first person to experience an issue using Ethereum tools.\nHardest to learn about the stack and opcodes\nFind the right local communities and get involved with them. Pair programming and being equally confused together is really helpful.',
        'Are there any other questions we should be asking?': null
    },
    '11': {
        'Name': 'Greg, Stu, David',
        'How do you handle smart contract verification and security?': 'Mythril, as mentioned above.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'David: EVM layer stuff: interactions between opcodes, JS dev and web3 also comes into this at the other side\nGreg: Reimplementation and adding functionality to the EVM and a lot of “bridge work”\nSetting up bridges, working with parity bridge and other existing contracts\nAdded efficiencies for personal needs to types when blocks are getting written. Basically recreated in the EVM to get a sender.\nWay blocks are written into the merkle tree.\nParity bridge is cumbersome because it is not well versionized and depends on the version of the EVM you are running/that you forked from. Often requires a ton of extra configuration.\nStu: solidity and PM (managing groups of people working at that layer of the stack), building smart contracts for clients',
        'What are the tools/libraries/frameworks you use?': 'JetBrains suite as an IDE. Remix comes in there for extra convenience but has it faults and is not totally integrated.\nBiggest problem with Remix is that it is written in jQuery and it is monolithic. Don’t know when it compiling/rebuilding contracts. Spinner doesn’t spin more than once, no responsiveness, very frustrating. Well laid out for an MVP ;)\nPass in data as strings and not having it parsed as strings is frustrating.\nWill meet with Remix team this week to advance development further. Seeing it as only 2 devs hammers home how under-resourced a lot of this software infrastructure is.\nDebugger has not really been touched since the first version. Critical software lagging behind is not good. Still better than the truffle debugger though.\nEVMLab - has an old school debugger that lets you step thru opcodes and examine what is happening in memory and storage. Has not been maintained recently, so you need to hack it together yourself.\nWeb3 and truffle sometimes, but not often. Often Remix and a couple RPC calls with console.log()s suffice.\nLooking over Mithril and visualisation of the control flow seems really interesting. Handles all the low hanging fruit, as an automated system should.',
        'What are your biggest frustrations?': 'Up to date documentation!!\nSystem dependence stuff would also be great to include (Mac OS/Windows/ Linux)\nThing s are fairly minimal, often have to hack together things yourself because the specific functionality you need is not implemented\nWhen doing tests, get very unhelpful errors. Make them more specific! EVM errors in general are garbage.\nTheir error handling, geth specifically, basically used the same error in most cases to propagate it out. Go through subsections of EVM and write proper errors[a].\nAre you going to be using revert with reason in that case?\nCall contract that deploys another contract. If gas is too low, it will just revert with no clear error. Needed to raise the gas, and it took 3 days of trial and error to figure it out (not clear if they will be or not, answer was more general about past problems they have had)/',
        'How do you handle testing?': 'Mostly unit tests in mocha and chai.\nMostly using Travis to automate the pipeline.\nProjects are fairly young and PoC - so not necessarily a major concern at this point.\nIf not already mentioned, are there any libraries you rely on regularly?',
        'What tools don’t exist at the moment?': 'EVMLab certainly has some of the features required, but they are very inaccessible\nDirectly execute arbitrary code and trace through it in nice fashion that is not just some JSON output.\nNeed to be able to step through those traces easily, which is also not possible there currently.\nGo implementation of parity bridge (to make it leaner). Only one bridge that is open source, so having another one would be useful, especially seeing as Parity devs don’t document well, especially changes between versions.\nSome level of standardisation around bridges and agreement about how they should be structured.\nWhat does interoperability actually mean in this context?',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Greg: Looked at web3 documentation (as it was more web based stuff at first).\nTruffle pet shop worked well for a lot of people\nDavid: Ethereum wiki was starting point, but you HAVE to talk to people about it.\nReinforcement comes through discussion and USE.\nStu: some limited solidity tutorials, go on to gitter and ask questions with code snippets nd other organic community involvement.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': 'Community! Going to EDCON was an eye-opening, validating experience. Impostor syndrome is real and the remote work can be very isolating, but you can also own that and it is inspirational to see.\nPerfectly OK to make stuff up as you go.\nAvailability of people, and the amount of people who can and will answer your dumb questions.\nAlso, it’d be awesome to actually put computer science background to use.',
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Where do we actually find out more about all these tools? ← highlight top-mentioned tools in report.'
    },
    '12': {
        'Name': 'Jon Maurelian',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'I work at Consensys Diligence doing audits; similar to Zeppelin.\nAlso, I do technical communications / writing blog posts about best practices around security / Consensys docs / token repos.',
        'What are the tools/libraries/frameworks you use?': 'We use Truffle a lot (never had to use Dapple or Embark)\nZeppelin used by clients -- would like to use EPM more\nRuns a Geth node myself\nSolhint linter\nSolidity Coverage is test measurement coverage tool\nETHGasReporter (Takes your Mocha reports and says how much Gas your test used.)\nWould like to see a fuzz tester.\nExcited to learn more formal verification + bringing into practice – intro to Sergio?',
        'What are your biggest frustrations?': 'Auditing:\nA lot of my time is spent understanding what the developer was trying to do. There’s lots of back-and-forth and I want to maximize the probability that this is the only audit the company needs to do (end up doing a lot of free work this way & comms);\nI would like to see better standards in what the idea of “ready to launch” is / what docs should exist / what the depth of testing should be.\nhttps://media.consensys.net/preparing-for-a-smart-contract-code-audit-83691200cb9c\nI want to see:\nMore efforts on gas optimization.\nUsing Assembly to do things.\nUse different languages.\nOne thing that kills me:\nWhen people copy-and-paste from Zeppelin or other libraries.\nAs an auditor: do I run a git diff?\nLarge inheritances.\nUgly repos. Not tidy. Clean directory structure is key.\nThese are real contracts.\nThese are testing contracts.\nWrote blog post so far.\nWhat are most prevalent errors:\nPeople should use EPM to import / or Dapphub.\nAdd linting -> Solehint (?) / Solium.\nWhat happens in a security audit:\nRun the tests. Usually because of different truffle or testrpc version.\nHave npm scripts to run local version of truffle.\nThe easier it is to read tests, the better.\nSelf-referential tests.\nCode coverage. Want all code to be run during testing; important code to be run multiple times.\nTest the full specification.\nStatic analysis: we use a tool called Nifroll (?)\nLook at Solc warnings & analyze bytecode.\nReading the code is the most time-consuming part. Best opportunity to make us all more efficient: automated tools to help auditor pay attention to right parts.\nThis is the most annoying part of the process.\nDevs need to have written down their intentions for the code.\nSpecification is evidence of thoughtfulness.\nUse Oyente; but it doesn’t find anything new generally.\nWe also think through game-theoretic attacks:\nE.g. front-running (transaction-ordering stuff).\nWhat’s ideal process for testing:\n1) run local testing\n2) run that test suite on some testnet.\nPut system on mainnet with 2 week bug bounty.\nE.g. ENS bugs weren’t caught on testnet. There was a typo that didn’t get caught.\nWant: more scenarios were there’s economic incentives to break the system – vs. just out of good will of devs spending time.\nDocumentation around best practices external to writing smart contracts\nE.g. how to safely deploy your system.\nThere’s easy tricks how to make this easier..\nThere’s lots of operational & security related info to share..\nBounty this into one doc as resource list.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Piper Merriam\nNick Johnson\nChristian Lundkvist (@ Consensys)\nJoseph Chow (@ Consensys)\nMike Golden (@ Consensys)',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '13': {
        'Name': 'Nick Dodson',
        'How do you handle smart contract verification and security?': 'Mythril will be useful when in full bloom - need more oversight on contracts in general',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Working on experimental infrastructure. ARES, GovernX.\nBuilding off-chain stuff - in order to conduct governance in organizational structures, most of the work is off-chain.\nWill also be doing on-chain governance, where they build DAPPs for ICO’s\nInfrastructure level stuff: infura.',
        'What are the tools/libraries/frameworks you use?': 'Solidity Compiler\nThe C version is very fast - but if you run the emscripten version, it’s painfully slow.  In transpiling process of C++ version, it drops down performance. The JS transpile needs to be improved.\nSolc compiler slows down development time. Ideal to stay in local JS (and not have to go back to solc), have it compiled super fast inline using a tagged template literal or something like it (using require(“solc-inline”) or equivalent).\nCould write `solidity` in backticks and have it compiled all in same file.\nWould make experimentation and testing much easier and faster. Could potentially provide some specs/API for this. Will provide further specs via email.\nTrying to build complex systems with 20 contracts and everytime need to wait 20 minutes\nTestRPC + Geth Client\nNot well maintained - ask Truffle team.\nPeople are trying to get away from it - people want to test on GETH / Parity and use them to run their own Geth nodes, but it’s a pain in the ass.\nWas working on Geth library that allowed you to run in Mac / PC with JS\nUsed Geth like Testrpc - allowed you to test contract codes against all clients (Geth / RPC / Parity)\nNever finished, but definitely needed.\nIf you’re running contract tests locally, TestRPC is only ETH JS VM. This is, however, not the VM most of miners are using, and that can be cause for concern.\nCan we make testing contracts against Geth easier? NodeJS Wrapper against Geth (most people are using Truffle - would be happy if Truffle had a module for this)\nTruffle uses Ganache which is ETH JS VM - this isn’t used in production.\nTruffle involves hassle of having to download run and configure GETH\nMaybe a wrapper or easy install script - run Geth like TestRPC',
        'What are your biggest frustrations?': 'Data verifiability problem - nobody is going to another source of data\nRun your own local system and test whatever is run by Infura vs. your system -- should be able to test this against your own local Dapp\nNot a lot of utility to compare -- would be great to have library and testing script\nProtection mechanism to keep an eye on infura -- ecosystem driven thinking to reduce amount of trust to test what they are giving us\nExchanges should be running internal nodes to make sure getting the right data - need something to compare their node to Infura\nBuild a Dual Provider. Make a little library, connect your own provider and Infura, and then compare that both are behaving the same. Verify yourself\nETH.JS Stuff - small items\nWebsocket support\nMoving ABI module to Richard’s module',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Tell us more about TCRs and DAOs?\nThere are many groups that need it for protocol or token\nRendered basic systems and services that we really need\nNotifications - if you’re in governing body, you need to be notified via normal devices to conduct governance\nWorking on notification systems for TCR’s, multi-sigs, Aragon DAO’s\nScraping chain data and issuing emails - databasing and emailing. Should be easy to do.\nVerifiable chat system - most governance is about the conversation.\nLow level real time, high performance, contractually restricted chat. This is centralized, but data storage is decentralized and data content is verifiable.\nCan be encrypted using RSA\nWill spin out live chat for ecosystem - enhance dapps with real time live chat\nData / Statistical Analysis - Alethio (deep rich blockchain analysis system)\nLots of data coming in for governing structures - no reason to load from Infura\nReporting and data analysis on governance structures\nWhat is participation like?\nHow well is a TCR performing?\nOff-Chain verifiable polling - votes and data are verifiable\nCoordination is only attack vector.\nFinal tally is rendered sum of onchain and offchain sum\nHow can off-chain channels be made into a near-front end experience?\nHow are API’s made in a very simple manner',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '14': {
        'Name': 'Ilan Benbrith',
        'How do you handle smart contract verification and security?': 'Consensys Diligence provides some of the best resources and best practices online',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'I’m the Technical PM at Consensys Academy working on an 11-week developer program. I’m responsible for maintaining the course and making sure people reach their development goals.\nThe course is for experienced developers - experience with languages/git required.\nOverall objective is to attract people to and grow the Ethereum community\nContent creation, assignments, course, customer/student support, external resources, connection with Consensys mentors\nThe course starts with intro to blockchain in general, so that students don’t have to know too much about blockchain. Historical context/ timeline, technical underpinnings of blockchain, technical underpinnings of Ethereum. Difference in mindset between traditional development vs DApp development.\nTeaching them the setup and tools they’ll need for the program (Truffle, Ganache, Remix, etc.)\nThen EVM, Solidity/smart contracts, connecting a front end with React Native\nSecurity smart contracting and auditing with help from ConsenSys Diligence\nFinally, different integrations (IPFS, Oracalize, etc.) and design patterns of different teams.\n LLL, Assembly language for the EVM, Vyper.\n Ethereum Improvement proposals/ Ethereum Request for Comments processes',
        'What are the tools/libraries/frameworks you use?': 'Truffle, Ganache, Remix, Metamask etc.\nFront end\nReact Native\nLLL, Front end libraries\nWe give wide exposure',
        'What are your biggest frustrations?': 'Gas and fees is a common frustration, given that they are an extra consideration that must be taken into account. Test Ether required.\nSpeed, once launched on mainnet latency is frustrating.',
        'How do you handle testing?': 'Truffle testing\nBest practices resources',
        'What tools don’t exist at the moment?': 'Drizzle is a really cool idea for front-end development',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': 'We’re still so early on but we hope to incorporate feedback for now.',
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Youtube videos\nConferences and Meetups - putting names to faces, seeing others’ pain points\nWatching someone build out an application',
        'Are there any other questions we should be asking?': null
    },
    '15': {
        'Name': 'Goncalo Sa',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'None come to mind right now. Let’s keep the focus on EthPM here - we need to make sure as many people use it as possible! We should have done this a long time ago and we need to dogfood it as a community!',
        'Who are you and what are you working on?': 'I work at Consensys Diligence - focus on security of the ecosystem. Everything that is related to security: it’s on our roadmap to tackle it.\n95% of our work today consists in doing security audits on smart contracts - any EVM-compatible or “compilable” code. That accounts for building security tools that do the checks automatically, or that assist on manual inspection.\nThe goal is to eventually encompass everything related to Ethereum security.\nI have always been hacking - a grey hat of sorts.\nBuilt an ad tech startup, which had a built from scratch ad server that I did the architecture for.\nHad a mobile app to tell Portuguese people what was happening in their city.',
        'What are the tools/libraries/frameworks you use?': 'I used to use Remix a lot more than I do today (though I still use it heavily).\nUse it as a text editor, in fact, but mostly for debugger when I am auditing, especially when trying to prove/disprove an attack I have thought up.\nVisual debugging feature helps me a lot. It’s not perfect, though.\nWe’re fans of dogfooding, so I use Mythril a lot, which was initially created by Bernard, but is now being developed by a bunch of people we hired.\nUsed mostly for automatic detection of errors.\nOyente is falling behind a bit, so I haven’t used it in a long time.\nManticore is not built by us and does the same thing as Mythril (we have compared it). Though the inner workings are very different, the result is largely similar.\nHave played with, but never tried to integrate, Enchidna into my workflow, as it is difficult to work with due largely to deadlines.\nRattle is closed source, so haven’t yet got around to playing with it.\nI extended a tool from Federico, who has an ANTLR parser for solidity, that is basically a viz and query tool for solidity contracts. Everything from inheritance trees to function call graphs and querying function paths in the function call graph. It is a tool to help with manual inspection particularly.',
        'What are your biggest frustrations?': 'I really, really want a good visual debugger. I don’t think I’m alone on this one either, but I also don’t think people are as passionate about this as I am.\nMy main motivation behind this is that I really like visual debugging and it is just so much easier, when debugging a very low level program, to have a visual aide.\nIt requires real experience to reason about things at a very low level and see the effect of each line of code.\nRemix, right now, has a very steep learning curve and we are missing the opportunity to make sure that every developer coming in gets clear insight into the nitty gritty details, the fine print, of the EVM that actually gives them full control over what they are doing and what they want to do.\nI feel that very contained environments are usually more appealing to people just entering the world of computers and programming.\nWhen Apple started with Swift playgrounds and lots of integrations, I saw a bunch of people just flocking into iOS development. It was just so easy to understand what is happening - it’s all very visual and easy to grok.',
        'How do you handle testing?': 'Remix, Surya and Mythril as above.\nVery small number of instances where I need to do something off chain, for which I will then use Truffle.',
        'What tools don’t exist at the moment?': 'A proper, local dummy client. I love the Truffle team and I love Ganache, which I use a lot.\nI run a lot of tesst on Ganache, which are not seamless to run on other machines, so I would love a super seamless cross-platform client that has a great block explorer in it.\nUsing the visual version of Ganache about a month ago, I couldn’t see events being fired, or various important details on transactions happening there. We need a more full-fledged local client.\nWe haven’t really prepared for how to handle contracts across shards (coming months to years, who knows?).\nWe are looking mostly at tools to support the WASM architecture. This is likely the problem that will take the most of our time, I think. I have talked to Johan Barbie about this and I’m not sure anyone has a very good solution for what a tool that would help scheme the interactions out actually looks like.\nI am personally more worried about language design stuff, and languages in general, than I am about the consensus layer, or anything below the language and application layer.\nWe are also working hard on updating our tools to support, for instance, Vyper. John has been doing a terrific job there, doing contract translations from Solidity to Vyper, built a plugin for Truffle.\nMythril will also eWASM at some point before it goes into production.',
        'Other domain specific questions?': 'What are the details/patterns in smart contract audits you see often that people should not be writing?\nPeople are lacking the granular insight that is required - along with the right mindset/philosophy/paradigmatic approach to writing smart contracts. This goes back to the need for better visual tools, in my opinion.\nA lot of contracts do not acknowledge that they are operating in a resource-constrained environment. For instance, I see lots of loops - which is not a desirable thing when operating on top of Ethereum.\nPeople also don’t have that “asynchronous mindset”, unless you have been working with a very strange stack indeed. Even people coming from JS and pure node backgrounds - it’s not quite the same thing.\nThey keep favouring push mechanism when there should be a pull one (or vice versa).\nIn reality, this is a very hard question. I do have a collection of very specific stuff I have seen people do wrong, but - in a very general manner - the biggest problem is bringing synchronous patterns into smart contracts.\nThinking of a way to have them do otherwise, this whole thing is promoted by people not getting what is actually happening beneath their code. They know it is “distributed”, but what does that mean to them? Hence the need for something like a Swift playground in order to make it easier to grasp the use of resources on the network',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Bernard Miller from our team, focussed entirely on Mythril.',
        'What are the best educational resources?': 'I do this less frequently now, but I basically watch every interesting repo to know what they are doing next before any announcement or anything.\nI also spend a lot of time reading the docs in that repo. In fact, a couple years back, I would spend most of my time reading those kind of docs.\nAlso, the Ethereum wiki has a lot of super involved stuff that is not easy to grasp and there should be somewhere where those things are explained far more simply.\nAgain, I’m a very visual guy, and that wiki really lacks graphics and images that could be really helpful in terms of giving a wider group of people insight into the innards of the systems.\nThings like RLP encoding, Patricia-Merkle tries, or the ABI sender (which I went back to over and over again until eventually getting to a sort of Eureka moment re encoding reference types). I feel like the tries, in particular, are very visual things.\nRLP graphic resources would really help because it is such a specific thing.\nThe Beige Paper is awesome, but it’s still not the end game - it’s too technical still with almost no visual guidance still requires a very big leap for people dealing with blockchain for the first time.',
        'Are there any other questions we should be asking?': null
    },
    '16': {
        'Name': 'Fabiano, Jordan, Nick',
        'How do you handle smart contract verification and security?': 'Audit code: bounty hunt program, found one major one via community. Ran our own repo specifically for this on Github.\nCommunity auditing through bounty programs.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Cryptokitties! Goals they have are to get multiple millions of users, the sooner the better. Ethereum sharding would be very nice, but even then there are scalability problems. Looking into other chains, EOS, Neo, Cardano  Looking at things from a scalability perspective.\nBack-end stuff reconciling state of the world between blockchain and their stuff',
        'What are the tools/libraries/frameworks you use?': 'Been a while since we have done smart contract development, haven’t done any since we deployed. Truffle framework, TestRPC (now Ganache). The standards at the time.',
        'What are your biggest frustrations?': 'The lack of proper debugging support. That caused us to lose so much time. Even more than the slow compiles.\nBiggest pain points:\nWhen we were using Solidity, some safety features were added later, especially visibility modifiers on functions.\nThe compiler is very slow. Recompiling took ~30 seconds slow. T\nests were slow as well.\nNo easy way to debug.\nDebugging tool for Solidity, what would it look like?\nWrite “debugger” and it stops there.\nBreakpoints, step through code.\nQuite difficult to log something through a function. It would revert if it failed, even logging was failing. If a require failed it would be tough to find error.\nPlanning on working on contracts soon? Or moving on?\nHave plans for a MetaData extensions, push kitty images to IPFS, and have kitty image as a piece of metadata for the cat. That’s the big one.\nFront-end:\nweb3 is the only library required. The web3 works as any wallet solution has the implementation web3.\nWeb3 1.0 beta, 0.26. On webapp they are on web3 1.0 beta, seems stable for the browser.\nRead and write functions for the contract, nothing crazy.\nThe problem with web3 0.2: docs are not great at all.',
        'How do you handle testing?': 'Standard testing and using community to audit contracts',
        'What tools don’t exist at the moment?': '2 main areas with significant problems:\nData analytics and reconciliation btw on-chain and off-chain data.\nOur first MVP didn’t have a back-end at all but we had to develop a back-end as we scaled. Reconciling these quickly and correctly is key.\nAnalytics is difficult. Web3 and Geth, have to hook into data. But there are too many hurdles to jump to get these.\nIn particular, the biggest problem is when we want to deal with analytics where some of the data is implicit, like a series of transactions. One tx doesnt give enough data. When someone bids on a sale option in cryptokitties, bidder, price, and catId. Have those 3 pieces of information. But when you ask how many cats has this person sold? This info is implicit in a wider set of tx’s, all of which you have to fetch and then compare..\nPart of this is not them including this info in advance. A common problem in the ecosystem is that once you deploy something you need more info after deploying a smart contract and it’s hard to get this',
        'Other domain specific questions?': 'Have you written any open source tools for scaling?\nLooked into side chains and micropayments.\nSide chains as implemented in something like Raiden don’t allow people to build off what they build. On side chains kitty hats would not be possible.\nCryptokitties run son chain. Sidechains aren’t the option, but Plasma is really interesting to us.\nAre you writing your own Plasma stuff?\nWe’re looking for options that allow them to scale.\nPlasma seems possible in theory.\nWe chose Ethereum in the first place because infrastructure is good, Metamask, Infura, etc.',
        'What was the hardest part about learning to develop with Ethereum?': 'The real problems come into play when you are very dependent on 3rd party apps, in their case MetaMask. Memory problems in Metamask. Can’t really detect the state of Metamask. Stuck in a situation where they can’t provide the relevant info to their users\nWhen a user does something, it’s kind of a hope for the best situation. May take a long time. If a user buys something on Amazon, they get a confirmation in 30 seconds. In blockchain, we can’t guarantee that info. Spent a lot of time educating users. Less with the libraries and more with the user communication and understanding of blockchain.',
        'What are you most excited about in the short term?': 'The thing we are excited about most in the next 3-6 months is whatever ends up being the scaling solution',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Solidity documentation was quite good. Had all the jumping off points.\nRandom mishmash of articles and whatnot :)',
        'Are there any other questions we should be asking?': null
    },
    '17': {
        'Name': 'Andy Milenius',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'DappHub:\nWorking on dev tools since I got into the space in 2015. There were no tools at all; we wanted to create them in a holistic way from first principles.\nMade tools to make use of Solidity compiler & make Ethereum API & EVM simpler in general.\nFormal verifications & contract safety.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Ethereum relies heavily on Javascript dev tools; “that node modules way of life”.\nJavascript: its polarizing; you either love it or hate it.\nThe fact that there’s a JS tool for something doesn’t mean that it doesn’t need to exist otherwise.\nExamples:\nPiper’s python tools\n(would like to see C++)\nMaker’s bash tools\nSome dapphub Haskell tools\nEF should put money into language ecosystems; replicate what we have (more front-end library systems!)\nSecond layer tools - the Ethereum API is a huge pain point.\nRPC - if you’re on the command line, it’s a pain in the ass.\nHigh-level access into the Ethereum API; more granular than the REST API\nIn JS this is: Web3.py; in python its web3.js\nSmall drop in solutions for talking to a client\nWhy is there not a good robust solution for caching the blockchain in a normal database?\nMaker has funded this.\nVulcanizeDB done by Rick Dudley; Maker is funding\nWhen you talk to Infura, the Ethereum API, is mostly via HTTP. Need sockets.\nIf you want to query events, it’ll probably time out.\nIt will be cool if EF runs archive nodes, cached data.\nFeels bad about Metamask:\nIf you only used them to write to blockchain, then it would be so much simpler for them.\nMetamask just pipes all the requests to Infura; costs around 100k a month.\nThe reason why everyone uses Metamask, is because there’s no other robust solution. If EF funded a solution, it’ll be helpful\nMetamask is customer support for the entire Ethereum ecosystem.\nEvent querying\nMake it so that it’s not scanning for the whole blockchain.\nLight clients\nEveryone’s trying to build the perfect architecture. Metamask is trying to build something that works.\nMetamask’s version:\nAn awesome intermediate step:\nInfura publishes a block onto IPFS using pubsub\nAll the metamask nodes gossip it to each other.\nCould EF support this.\nThere is someone publishing all blocks from all blockchains on IPFS, into a meta-blockchain, called Braid.\nWhisper & Swarm:\nThere’s other people still working on these outside of ETH\nSwarm is similar to IPFS.\nDoes ETH need p2p messaging\nThere’s systems that work:\nDAT protocol / secure scuttlebut (1,000s of people on these networks)\nAsk the Secure Scuttlebut ecosystem what their issues are\nDfinity gave a grant to secure scuttlebut\nIt would improve the Ethereum community image if we’re working with others.\nIdentify other projects that are good; trim the fat from our ecosystem; and then build a relationship with them.\n“Living life on hard mode” – people who don’t do ICOs.\nOther ecosystems that are good: show commitment to Protocol Labs\nLibp2p\nIPLD\nMore formal partnership -- integrating properly\nDevp2p is bad\nLess than 1% of requests you make are Ethereum mainnet.\nYou contact other nodes without knowing if they’re on Kovan, Mainnet etc\nSuper inefficient; all these handshakes.\nMain bottleneck in Geth -- every ETH node talks on Devp2p\nGotta switch to libp2p!\nAre Geth team dynamics good?\nIdea: a parallel IPFS pinning service; as a hedge against Filecoin not working.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'How can Ethereum create more cultural norms and lead by example?\nTake a more leadership role to say nice things about other ecosystems, languages etc.\nEthereum Comm’s department.'
    },
    '18': {
        'Name': 'Esteban Ordano',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Biggest request: have ERC20 upgraded to ERC223.\nWe have troubles with small re-orgs – transferring immediately upon approvals causes issues.\nThis was a problem with our code; hard to develop.\nHave watchers on the Blockchain, and sending transaction to make correct transfer, e.g. for MANA token.',
        'Who are you and what are you working on?': 'I’m hiring two or three people – excellent engineers – to build tooling.\nWe’re calling the project Voltaire Labs, after the Voltaire house. Trying to get Sergio Lerner to help with that. Getting people I know from Google. Maybe we should join efforts? Will intro to Federico Bond.\nOur infra:\nMANA token which is an ERC20.\nAuction of Land.\nLand smart contract which is an NFT token standard.\nGot tired of not hearing back re ERC non-fungibles improvements. Proposed alternative ERC.\nLand registry of who owns which land parcel.\nThese link to IPFS or IPNS for content of land.\nDecentralized exchange of land parcels.\nSmall tool for sending emails whenever an event is triggered on your contract. EthAlarm: takes address of contract, ABI, pick events that you’re interested in.\nWe run the land auction off-chain, we had a period of registration where you’d send the MANA you wanted to use in the auction. At the end of the auction, we distributed the NFT tokens and returned MANA.\nAuction was mostly an independent application – better UX, less fees\nWhy the auction was off-chain:\nWe processed around 115k bids. The UX for the auction was great. We managed to provide the user with an experience that was way better, because it wasn’t blockchain-based.\nBoth on the browser and the server, we exchanged cryptographic receipts –– “I’d like to bid for the following parcel (x,y), (x,y) – at the end you’d receive a signed receipt” – the server would receive that message, and say back “I’ve received a bid, and here’s your receipt”. All these receipts are public.\nAnyone in the auction everyone could act as an independent verifier of the auction.\nWe returned a receipt had a nonce ––\nWe can audit the whole auction. Can prove every bid that we received.\nHow we’ve been running auditing\nWe sold $16m worth of parcels of land.\nWe wanted to make sure that they weren’t messing up.\nNot many people were checking – but a few did and even reported back some issues; community trusted them.\nWould be best if this was run on a decentralized protocol so people didn’t have to trust these guys.\nWe’re building a voting scheme with MANA:\n“How tall should this building be?”\nWe are repeating the same pattern as the auction.\nOur voting scheme is offchain and non-binding, because the project is early enough that people can back out.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Pains:\nThe gas issues – the expensiveness of the whole process.\nWe are subsidizing the whole process of deploying the land.\nWe are also subsidizing the second transaction after the ERC is assigned.\nThis whole process will take 12 million, 150 ETH.\nWe also had to make the contract upgradable – with the delegate proxy pattern\nWe are worried that Solidity will change, and the structure of storage will change.\nOur thinking: we’re doing some engineering on how to sell the next batch of land – we came up with a better system to sell that land – it’s going to be pretty neat. We’re not going to have this issue.\nDecentralized exchanges:\nLooking forward to 0x adding a version of their protocol for non-fungibles. Which has now happened! https://blog.0xproject.com/introducing-0x-protocol-v2-9f5bda04d38d\nState channels:\nLooking forward for Raiden\nWas thinking of funding Lightning Network for ERC20 network\nSimulating a UTXO model on ERC20 tokens\nWants for interoperability between Bitcoin and Ethereum.\nOlaoluwa (from Lightning) is the best coder in the world.\nBitcoin world is more secure.\nLightning code is written like poetry.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Should speak with Fede –– should collaborate together –– they’re interested in throwing money at sidechain & Plasma chain.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '19': {
        'Name': 'Matias Bargas',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'I used to be an investor, but came to crypto and Decentraland at the same time.\nI used to work with Juan and 2 other guys who all joined the team at the same time. I really wanted to leave enterprise companies and loved the team already there.\nIt’s about the open philosophy, and break down the walls around the 1% of the 1% and diffuse power into the hands of everyone.\nI was working on an online IDE for an in-house language at MuleSoft. Now the engineering manager at Decentraland.',
        'What are the tools/libraries/frameworks you use?': 'The whole Ethereum stack, basically.\nTruffle\nIntegration with common developer tools is not fantastic. We need to start thinking about and building our tools in such a way that is easier for the guy/girl who comes after me to fix the issues that come up.\nIf we are changing the world, why are we still thinking in narrow ways about how our tools should be used and by whom?\nVS Code\nReact, typescript, nodejs\nBablyon.js as an engine for VR\nWeb3\nOne of team members rewrote web3 into typescript for EthBuenosAires and all the tests are passing! Will post a link here after the hackathon.\nThere were typos there!\nThere was functionality not working (and there are billions of $’s running on top of it!)\nIPFS for decentralized deployments.\nScalability is a concern here. If we want to deploy the whole metaverse in IPFS, we actually can’t. We need to replicate data in, I don’t know, Amazon or something because we can’t supply the level of connection we need to (just 100,000 users or so, not even in the millions). And even this will require bootstrapping nodes like crazy.\nThe IPFS cluster is still in alpha and not as stable as we need it to be.\nWe are waiting for scalability, but we don’t have the tools to monitor and handle that amount of information anyway, and this is a concern for us.\nI haven’t used this yet, but this seems to be an interesting tool: https://github.com/nomiclabs/buidler',
        'What are your biggest frustrations?': 'Real monitoring information is tough to come by. I come from enterprise where this stuff just exists and the ability to fetch the data you want to fetch is never really in question.\nBrowsing through a node that has a huge list of unindexed transactions without all the information you need in an easily accessible place is hard.\nWith our own tools, we are building our own framework in order to move tx information from the blockchain to the db and from the db to the app.\nWe need transformations between each layer (which wasn’t that hard to build). But now we need a really generic way to do this and to publish it for people building DApps and using our SDK. And with a centralised DB, this is not possible.\nWe are failing with dev tools in general.\nLet’s think about Java a bit. You have the JVM, a mature language and a complete set of IDEs. You also have a tonne of framework for building Java applications. There are also great monitoring tools.\nLogging systems are a great and practical example of this. How can I log failures from Solidity without using events in a way which they weren’t really intended to be used? We need a Splunk equivalent.\nTerraform, AppDynamics, etc - these things don’t exist for blockchains and really need to be built.\nWe need to focus more on tech and shipping things and less on the people with money or how our token is performing.\nWe care about nothing but the tech we ship. We encourage others toward similar feelings ;)',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'Starting from the infrastructure stuff: we need a new language to describe all the set of things that you need to do in order to deploy one or more contracts.\nYou have you application made up of a set of contracts that are all talking to each other: we need a decentralized logging system to make sure they are all still working properly and the events that are being dispatched by the nodes are correct.\nA complete set of tools for testing. Truffle is not adaptable enough.\nThe work being done by Zeppelin on securing contracts and providing best practices around how to use audited contracts is great.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'The Decentraland client!! Woot woot.\nSomething that helps me to generalised solve side channels.\nStatus.',
        'Was anything easier than expected?': 'No, not really.\nActually, extending the open zeppelin stuff was pretty easy.\nSomeone tried to exploit Decentraland and because we validate with open zeppelin it was safe, and we got that for free!\nIt’s great to see that security is taken seriously (though I still have a tonne of concerns about managing funds on public networks).',
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'I came from a strange backend doing tooling for languages for the last 6 years, so I don’t have the right approach to learning for most, I think.\nShould be readable, reliable and consistent. E.g. I prefer typescript over js because it behaves as expected and has been validated by the communicated. Java > python because it also behaves better and more in line with your expectations. I need a language with only one way to do things.\nIf Solidity fulfilled this, why do we need to test it with javascript?\nI never did any course, I just read contracts and code that seemed interesting.\nStarted with Zeppelin’s ERC20 and went from there through GitHub and started writing little tweaks and commits myself.\nI had also had some experience with React, so that set me up well for DApps.\nHaving awesome and intelligent colleagues is such a bonus too!',
        'Are there any other questions we should be asking?': null
    },
    '20': {
        'Name': 'Nadav Hollander',
        'How do you handle smart contract verification and security?': 'Write down in plain text documents what the invariants are for the contracts. Just very clear human speak for how the contract should behave.\nThen write unit tests relentlessly.\nIdeally, there would be code review, but he is coding solo in his stuff write now.\nFinding an audit is a crappy process. No information on who is doing it, what prices look like, which auditors are good / have good reputations.\nTalked to zeppelin\nTalked to Consensys diligence\nTalked to Quantstamp',
        'Other bounties?': 'A GREAT SOLIDITY DEBUGGER\nA turnkey solution to the “trusted relay chain” thing. Just make it easy for people to spin up a side chain, run their programs on it, rewind history to a specific point in time, etc.\nAlso let you set up rules on it like locking up deposits for a week between the side chain and the main chain.',
        'Who are you and what are you working on?': 'Building Dharma - open protocol for tokenized debt\nPretty much exclusively at the contract level, sometimes using stuff like libraries that wrap around contracts.',
        'What are the tools/libraries/frameworks you use?': 'I like to use Typescript for testing.\n0x team built a great tool for generating typescript tests from ABI’s\nUsing truffle to test.',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Truffle to write JS unit tests.\n** There are not good mocking libraries for solidity **\nHad to roll my own mocking contracts for testing\nA better native solidity testing framework with mocking would be awesome\nNo manual testing.\nIt’s still pretty painful to do this too',
        'What tools don’t exist at the moment?': 'Good logging and debugging\nSetting up your own side chain easily to test things on because it would be way faster',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': '“What is the thing that makes debugging solidity code the hardest?” (for me, it’s that you can’t log anything at all, and no working debuggers)'
    },
    '21': {
        'Name': 'Alex van de Sande',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Finding talented people is very hard. They are in such high demand. Trying to get people out of school. Online courses in Solidity.\nWeb developers, software engineers.\nSeparate recruiting approaches for the Foundation.',
        'Who are you and what are you working on?': 'Working on Mist, the Ethereum browser.\nDevelopers contributing open-source.\nThere’s a wall between core team & open-source team.\nWould love for people to be paid reliably for features.\n3 Developers. Talk on Discord.\nCurrent experimentations in paying open-source developers:\nColony\nCommit F\nWe want beter Github integration. Now possible with Status Open Bounties and Gitcoin etc.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Securing Electron (desktop JS) was hard. (JS in website can take over your system - happens with chrome)\nIntegrating with other technologies: IPFS, Swarm, etc. Frustrating that they are all in their early days.\nInformation overlap - this is a major problem - e.g. in keeping up-to-date with Solidity developments, even though I’m on the Foundation.\nA lot of people have been trying to integrate this information without success\nI like two things from the Foundation:\nDaily standup for Geth team.\nEvery quarter Vitalik and Ming post an update on what happened in the Foundation.\nTo be improved at the Foundation:\nOn the operational side:\nMake the foundation more open, more modular with their finances. Each team should have more autonomy, with their finances transparent on the blockchain.\nOn the technical side:\nAutonomy would play into this as well.\nWhat are you excited about:\nCasper.\nSharding.\nApplications: Aragon, MakerDAO.',
        'How do you handle testing?': 'People build new features, we check, and then approve it.\nWe’ve had issues –\nMeteor.js migrating to React.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'One dev working on a backend integration – I stopped working on this to work on one issue – “password wasn’t working for user” – couldn’t reproduce the bug. Could put a bounty for someone to recreate the bug & solve it.\nDifferent systems: Gitter, Github issues, different wallets\nHow we solved: created a single issue with all comments from other issues. Created google form for anyone who had an issue, to see if there’s a pattern amongst problems.\nWhat type of expertise is needed for this: we don’t have enough security oriented people on our team. We passed the bug reports to the Foundation security person, who tests them.[a]\nSingle case: serious bug report came in and was fixed. But couldn’t test the fix, because they would have run exploit on their machines. They don’t have pen testers.\nWanted – less of a wall between their team and the outside.\nNeed:  Recurring open source developers --- that are working for bounties --\nThey haven’t tried bounties yet.\nIs the problem: dev awareness or payment?\nThey’re making app more modular.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Nick Johnson\nRyan Zurrer',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '22': {
        'Name': 'Nick Johnson',
        'How do you handle smart contract verification and security?': 'Write a spec and define edge cases and corner cases\nLots of unit tests\nMake a point of testing where you intentionally break\nUltimately get it audited\nHow will this get easier for beginners?\nOpen source solidity libraries so that less code needs to actually be written by beginners (just 10 lines of customization)\nBuild some of these best practices into static analysis tools (linterns on steroids)\nSolicit crowdfunding to pay for the audits of projects that the mainstream is interested in\nOpen Zeppelin appears to be the best open source solidity library out there',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'ENS: documentation, smart contracts, UI’s,\nAuditing other smart contracts\nOther smart contracts\nEther cards\nOffchain: dev tool, EVM static analysis tool,',
        'What are the tools/libraries/frameworks you use?': 'Open Zeppelin tools are increasingly good. But try to keep the smart contracts as small as possible\nJust web3 itself in terms of javascript\nETH Gas station and etherscan are useful for different reasons',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Truffle unit testing with mocha\nAdded built in testrpc\nTestrpc still doesn’t have big number support for certain signatures so we have to fire up a geth node',
        'What tools don’t exist at the moment?': 'Byzantium added return data size (prevents arbitrary return data size limits). Once solidity implements this, it will be possible to return strings and stuff.\nAutomated updatable smart contract?',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Becoming familiar with the execution model\nYou don’t store the results on the blockchain, you store the invocations (because the computer is entirely deterministic)',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '23': {
        'Name': 'Elena Nadolinski',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Documentation\nDebugging, so helpful. A debugger with a memory view but without using Remix. Online IDE is not great UX for a developer. Coding in a website not a great pattern\nSomething that abstracts away MetaMask. An Open Source core. They are using a Chrome plugin because they are storing your private keys on your browser\'s local storage. If you could provide a core of this is how you talk to Infura.\nDesign system patterns. They really stick blockchain in your face. Want to sacrifice accuracy for a better UX. Design system. Very interested in participating in this.\nFigma does a preliminary case study on design in the Bay. The crypto teams that do design use Figma. Corporate Design system, open source Figma file.',
        'Who are you and what are you working on?': 'Last 6 months have been working on Solidity, Ethmoji (like Gravitar for Ethereum).\nWent to ETHWaterloo, have done talk at Hackathons about NFT’s. Make your own NFT from scratch at ETHDenver. With tools that we have, things are not as hard as people think they are. Can write something in 20 minutes with tests!\nOpenZeppelin came up to her and invited to talk at ETHBA.\nWith EthMoji wanted to make it the best smart contract as possible, wanted to make it upgradeable.',
        'What are the tools/libraries/frameworks you use?': 'Use Truffle because it’s by far the best framework for testing. Used Embark and Biddler, used Remix a bit for debugging things in memory. Memory explorer would be fascinating. In Solidity everything is a hash table. No case at all for catching hash collisions.\nOpenZeppelin, played around with ZeppelinOS but would use it more in the future.\nVSCode with Solidity plug-in, almost never have problems.\nEth-gas-reporter is amazing :)\nCommand line tool for code coverage, Solidity-coverage is a mocha plug-in',
        'What are your biggest frustrations?': 'Lack of error messages, since Solidity 24 you can add messages. But it’s not backwards compatible. More visibility on what failed and where, that would be extremely helpful.\nDo your own Metamask. As your client you don’t have to run your own Node, but want a way to abstract that. Don’t have to rely heavily on Metamask. People get confused on why you need Metamask.',
        'How do you handle testing?': 'Truffle for testing. Force people to do TTD in events!\nTruffle is not efficient in deploying things, can have a deployer contract that handles with more gas efficiency.',
        'What tools don’t exist at the moment?': 'A lot of tools exist but aren’t being utilized here. There’s no reason that Travis can’t run with Truffle. But this pattern doesn’t exist. Now that we have upgradeable contracts we can think of smart contracts like regular development.\nDocumentation, for a beginner starting out it’s extremely difficult. Not that many good tutorials on how to use technologies together.\nIndex of good tutorials. For IPFS in a smart contract. Want more deeper tutorials. Want to understand the why.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'It’s a myth for how hard it is. “I’m a Solidity developer” is associated with something difficult, but a smart contract is just a piece of code. Once that clicks it’s easier.',
        'What are you most excited about in the short term?': 'Quitting her job to start her own project so very excited about that. Excited to explore privacy in tech. Crypto is binary, either it fades aways or takes over the world!\nScalability and stability are covered. But not a lot of people are focusing on privacy. Monero and Zcash and explore others, but they’re pretty slow.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Christopher Gewecke, Wyvern team',
        'What are the best educational resources?': 'Personally found a couple Medium articles here and there, Medium article on how to do your own ERC20 coin in 60 minutes or so. Had to Google a lot.\nGood article on NFT’s, read the docs website for Solidity. For a beginner it’s hard\nVarious projects have good resources, Dharma has a good walkthrough. Collateralize an NFT, you have a loan on a CryptoKitty. Walks a beginner through step-by-step.\nCryptoZombies is really good. They do a really good job. They move very quickly into advanced topics.',
        'Are there any other questions we should be asking?': 'Real world companies that are not tech savvy could benefit from blockchain. Want to sell art to the blockchain, that’s a day project. Squarespace or Wix for dApps. Patterns are so common. If we want to make blockchain more widely used, make this drag and drop and easy. Abstract that away.'
    },
    '24': {
        'Name': 'Swaroop',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'We are building EthVigil an API gateway to to help developers build apps on blockchain without worrying about nodes or RPC calls. We take any smart contract and turn it into a REST interface. Use a modified ERC20 token (and a hacked Remix IDE). So you don’t have to worry about encoding it, filling out strings, etc. Deploy it to a testnet. Even take care of issues that could occur on the blockchain.\nOnce it’s deployed it’s like a Swagger API, make all the Get calls, etc. Any web developer can see how it works. Setting up private keys, all that signing, all that stuff is taken care of (custodian feature). All you need is an API key, abstracts away some of the pain.\nDemoed minting some tokens. EthVigil goes deeper and will investigate if transactions will fail. Any web developer can use it upfront. Can add integrations, their system monitors the whole blockchain for events, can get notifications on Slack/email.',
        'What are the tools/libraries/frameworks you use?': 'Mostly custom tools. Started with web3, started with Truffle but was running into a lot trouble using them so rolled their own.',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Basic unit tests, integration testing. So much of the codebase that keeps changing so difficult to stay on top of testing, but have must stricter tests on mainnet. At the moment don’t have external auditing.',
        'What tools don’t exist at the moment?': 'Web3 is a library to make it easier for a lot of developers in the space. But we use JSON RPC calls directly, don’t want to abstract on top of this so don’t want to get anything in between this. Had some issues with web3py.\nRecommend that our customers use Truffle, Ganache, etc.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'The first thing I built was a tool that looks for any ERC20 transfer automatically. Built in one month. Not just writing code but understanding the Ethereum paradigm. But I’m not a finance guy or trader so wasn’t super excited about this.\nCurrent error codes are not that useful. Getting a response back saying 0x from JSON RPC for some very weird reasons, but doesn’t handle errors in a great way. Better error codes. Wanted to jokingly call themselve the 0x company but it was already taken.\nLack of documentation, but it has improved a lot..\nDealing with the clients themselves, not using Infura. When you use clients directly and bypass Infura it can be painful to get things running.\nThere’s no flow at all really. I would randomly learn a bunch of things but nothing flowed together. I bought Ether but didn’t need it to actually build on the blockchain. Ropsten was down all the time. Did our stuff on other Testnets.\nMaybe we need to have a flow of learning the fundamentals. It’s all out there but it’s not connected.',
        'What are you most excited about in the short term?': 'We built a platform to help people use blockchain but people don’t know what they can build on blockchain. We think Digital Assets are the next big thing, CryptoKitties are the first step in showing the world what they can do.\nThey are setting up their company in the old way, but can do stuff on Ethereum. Writing stock on the blockchain could be a gamechanger. Document signing.\nI hope the scaling issue will be solved soon.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Barely anything with tutorials when they got started. He gave his cofounder a crash course in a couple days, and then his cofounder went off and did a self-study. Some good videos were out there (Udemy?)  that they bought. But the best thing is to do it on your own, especially because they are operating on a lower level.\nRecommend to go to Ethereum main’s website but not friendly enough for beginner to intermediate developer. But this is a paradigm change, completely different way of doing things. Have to educate the developers.',
        'Are there any other questions we should be asking?': null
    },
    '25': {
        'Name': 'Alex Beregszazzi & Pawel Bylica',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Pawel - focused on VM in general, spent a lot of time designing / optimizing the EVM for the future.\nExperimenting with new ways to make the VM faster for future upgrades\nClassic code optimization - added some small features to EVM (like Revert / Return Data Buffer / Shift Operators)\nWorks mostly with Alex -- changes in Byzantium were with Christian\nJoined 2-3 months ago\nMaintained C++ code base for Ethereum client -- experience with EVM\nAlex\nStarted with building dApps, contracts, UIs – everything was broken in 2015.\nThen jumped into proposing things and fixing things;\nSolidity\nTesting\nJavascript\nLed to working on testrpc & ganache-core\nWorked on Trezor, and build a dApp for it.\nEnded up with all these other issues: cpp-ethereum; testrpc; RPC methods.\nTried to raise issues, and sometimes they end up in improvements.\nSpends most of his time in Solidity design.\neWASM – started 3 years ago for 6 months – then took a big break – then now working on it for 3-4 months (really started in Jan).',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Communication is bad within EF and within ecosystem in general\nPeople aren’t aware of existing products / solutions\nDuplicate effort solving the same problems\nNot everyone agrees on the same communication channels –\nPeople use different tools\nSeems to be fixed now with Gitter.\nLack of resources\nPeople jumping across projects\nWorkflow on EVM / eWASM – problems (below):\nAxic: Review process\nOn Solidity – we’ve grown 200%\nSome people are remote; a lot are part-time\nThere’s a lot of onboarding\nBecause of onboarding – not everyone’s review is equal, takes some people with experience and insight.\nIt’s very easy to block people\nGithub Projects kinda helped this process:\nOrganize features into versions.\nThey had a label for breaking changes;\nShould be clear from the PR list.\nBacklog is really large and growing. There’s too much that we don’t have enough time to get setup project management process.\nFor every PR, someone has to learn all the subsystems that are involved. Solidity is a big codebase.\nIt’s a complicated codebase; needs refactoring\nThree ways of generating bytecode from AST:\nWay 1: cpp stream of instructions, values, and comments\nWay 2: append inline assembly\nWay 3: compile Julia into bytecode\nOur focus is moving to Julia, and using that to generate bytecode.\nWe’ve planned a full rewrite of the “code generator” subsection.\nBut they found a way to do it without a full rewrite.\nJulia:\nHas an internal AST, a parser, a syntax for the parser.\nBackends: which generate bytecode from the AST->EVM, EVM15, eWASM.\nTransformation steps: things that happen on the AST; could be built independently.\nThese exist for EVM and EVM15.\nBuilding these for eWASM could be a task.\nBut they’re good on-boarding work for new contributors.\nThe external static analyzer:\nWritten in Javascript.\nCurrently part of Remix.\nTry to use a number of options that the compiler gives you.\nThere’s no option to turn off warnings.\nTherefore: anything there is a warning, you should fix it.\nDelegating warning generation for things that are conventions to this external static analyzer.\nTwo major things to be done for bounties re the static analyzer:\nBounty #1) Separate it from Remix, and make it independent.\nBounty #2) It uses the old AST format, that the compiler used to generate.\nIn other words: the compiler parses, creates an AST (which is a big JSON object), which is then passed to the static analyzer\nThe new AST JSON is much more compact –– but means that the static analyzer should be written.\nThis could be more iterative.\nMist has this notion that it has Solidity compilation built-in.\nConsiders “warnings” and “errors” the same –– so throws.\nThe homepage has 1) old Solidity examples (which has errors), 2) recommends Mist (which throws errors for warnings).\nPawel:\nMaking cpp-ethereum more modular.\nStarted removing some parts, and moving it to different repos.\nTwo things:\nA Proxy for JSON RPC.\nMaybe should write the Proxy in Go.\nWhat it is:\nPreviously, we had 1) an HTTP server to handle the requests, and 2) some Unix sockets to handle other incoming requests.\nThe HTTP server is replaced by a simple Python script. Replaced the HTTP requests with a Unix socket requests, so same underlying system can be used.\nThere’s no reason for implementing all the transport layers in each client.\nThis Python script only exists in cpp-ethereum, but should be included in other clients.\nOnly complaint about Python: it’s hard to ship an executable object of code.\nA proxy for the p2p network stack\nSame as above, but for the networking layer.\nE.g. devp2p or libp2p protocols.\nYour application protocol (e.g. Ethereum or Swarm) connects to a new p2p layer.\nWe should instead use the same p2p layer.\nProblem: duplicated effort of implementing the same things.\nNeed a nice interface for inter-process communication.\nCan combine different parts of the stack in different languages.\nEVM-C: C interface for EVM.\nShould stay 
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '26': {
        'Name': 'Christian Reitwiessner',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Gas profiling:\nSolidity does some upper-bound gas cost estimation – but its not very useful because it’s just an upper bound.\nHow to calculate: run the EVM with specific inputs?\nOr: run the function with larger and larger arrays; and find a “gas function” as a function of input size. But this also depends on state.\nSolidity – 16 stack slots issue:\nSoon: we’ll have structs, and this will be less of an issue.\nWhen we have IULIA, this requirement will go away.\nWhen IULIA compiles to EVM, it can move variables from stack to memory, after analyzing which is used or not.\nInteresting: IULIA will compile to eWASM.\nInlining common function calls:\nWe’re conservative when it comes to adding new features in the code generation flow.\nWe already have an optimizer for IULIA which does inlining; so that will resolve this.\nThe optimizer (in solc) has a switch which decides what to optimize for: code size, execution cost.\nThis exists, but is rather crude – it assumes every opcode is only run once and this assumption breaks down if you have a loop.\nHave Remco share his 0x example with Christian – and how it could be improved in terms of gas estimation.\nConstant delegation.\nHave Remco to share example of hash not being calculated at compile-time.\nHaving a good technical writer – who can understand the technical details of Ethereum, and improve the documentation.\nAnother model could be to create bounties for improving the documentation. Won’t be bounties for a specific issue; but general rewards for improvements to the documentation.\nImproving the documentation for Solidity\nThey’re too deep inside this. Having an external viewpoint would be helpful.\nIn the research area: due to the way research funding works – people publish the work, but do no maintain the software or integrate with other tools.\nIntegrating research software with development tooling & keeping them up to date.\nBig example: Formal Verification software\nFive or six tools that similar to Oyente.\nRemix has a plugin architecture – possibly supports Oyente.\nIdea for tool: being able to test very quickly if a contract implements an interface.\nThe problem is that you cannot enumerate the functions of a contract.\nThere’s a way to resolve this.',
        'Who are you and what are you working on?': '90% of my time: design of Solidity language and its implementation\nFormal verification part of the language –\nDeprioritized over the last 2 months. Will take on again in April.\nOther projects:\nGeneral research\nLess research re sharding or plasma – More research on computational scalability of SNARKs, STARKs, Truebit\nHanded off cpp-ethereum to Pavel – not working on it as much.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Tell us more about computational scalability on SNARKs, STARKs, Truebit?\nResearch on SNARKs implementation – ZoKrates project. Only a PhD student right now – Jacob.\nA toolchain for creating ZkSNARK-enabled smart contract\nNeed help there, and can pay $ for it.\nWhy they haven’t focused on getting more people, is the project management burden there.\nWhat kind of help we need:\nImplementation.\nThe project is a compiler that takes a high-level language, turns it into an arithmetic circuit. It’s PoC stage right now. Also needs help with the direction the project needs to go. Needs an evaluation of use-cases.\nAlso needs people with cryptography backgrounds who can implement efficient arithmetic circuit gadgets.\nSomeone who can deal with Rust as a language; finite-fields.\nOpen-source on Github.\nPotential help: university research partners –– Dan Boneh?\nIt’s early, PoC stage. –– currently the elliptic curve pre-compiles are too pricy.\nThe first step is to see how much it costs, and if it’s feasible because of this.\nAnalyze use-cases, and see whether its not too expensive.\nImprove the trusted setup experience.\nSolidity?\nDevelopment resources: we’re pretty much good right now.\nWe have issues marked: “good first task” or “help needed” – these are good to pick up by external contributors. They’re small in scope, so maybe doesn’t make sense for large bounties.\nUsually someone creates a PR, we have comments, they update the PR, we make comments, then the contributor loses interest.\nMaybe: could have a person who is responsible for external contribution across all projects?\nAnother project: analyze external contributions, and understand why they weren’t completed. What was missing in the description / what was the issue? If you’re creating an issue for external contributors, what is the detail / info you need so it gets picked up.\nWhere we need help:\nExternal people to translate the documentation.\nThis is a big effort. Requires management. Need to keep translation up to date.\nThis doesn’t really exist right now. Only have a Russian / Spanish translation that are old and rudimentary.\nThere’s people to do the translation –– need someone to do the project management.\nMore feedback from people who try out the most recent version of Solidity before it is released.\nBefore – Remix was set to the most recent development snapshot. Now it’s set to latest stable, so don’t get immediate feedback.\nTruffle and etc only upgrade manually – so its more stable – but slows down the feedback / dev cycle.\nHow would this work:\n“Reminder: people please try out new versions.”\nWay to give feedback exists: creating an issue on Github OR their Gitter channel.\nMost people can’t use the latest the version – because the toolset doesn’t allow it.\nAs part of the CI, we’re running some tests with specific libraries.\nPossible solution:\nPeople submit their contracts to Solidity team.\nThey get integrated into their CI pipeline – every time a new version is pushed, their contract tests are run.\nWe get contacted if tests pass re new version working.\nTools for developing Solidity\nIt’s written in cpp, we usually cmake toolchain for building, cpp-ethereum for semantic tests; thinking about switching to their own interpreter to speed up tests.\nUses cpp-ethereum with a few extra RPC endpoints. Let’s you rewind the blockchain to a particular block. It’s also allows you to modify the timestamp in the next block.\nThey’re standardizing these API endpoints. -> include ganache-cli in these discussions?\nGanache needs to have this ability.\nHaving a testing only Ethereum blockchain\nHas a memory-only blockchain; is mainly meant to run tests on smart contracts.\nSimilar to ganache; but performance could be improved?\nGanache has a UI\nTo improve: high-throughput, many txes at once.\nNotes on IULIA:\nCompilation from IULIA to EVM is finished.\nOptimizer is 90% finished.\nThis is why the ABIcoder isn’t out yet, because it 
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '27': {
        'Name': 'Fabian Vogelsteller',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Need good IDEs:\nRemix is good, but has problems.\nOmkara – Remix for Atom. Sophisticated Solidity IDE for the Atom browser\nThis project can get a lot bigger. Could add debugging.\nFormal verification\nWrite specifications for smart contract implementations, generated proofs that can be tested against EVM code.\nSmart contract security / best practices\nAlso comes down to an editor – gives you recommendations, formatting, etc.\nMore examples in the Solidity documentation\nThere’s someone at the EF working on documentation now.\nUnit-testing for Solidity contracts\nDapple: a tool for testing Solidity contracts using Solidity contracts – unmaintained for 2 years now.\nHow is it that we don’t have unit-testing for Solidity contracts?!\nOpenZeppelin works on these audited pieces.\nIdeas:\n“Results-based” bounties.\nhaving smaller tasks, having a lot of eyes on the project and setting smaller bounties.\nIncentive structure for the reviewers & maintainers.\nIdea: standing bug-bounties for large ecosystem projects & contracts, funded by EF.',
        'Who are you and what are you working on?': 'My future project: Lukso blockchain: EVM-based blockchain.\nWorking on industry-specific blockchains.\nBuilt the Mist browser and Ethereum Wallet(worked with Alex van de Sande, who came up with the idea / design, and Fabian built it).\nWorks on web3.js. Proposed ERC20, ERC725/735 identity standard.\nJoined Jan 2015 before mainnet. First person to make the user-facing / developer-facing tools intuitive. Simplified the RPC API.\nMy main focus now: half-time: web3.js & half-time: Lukso.',
        'What are the tools/libraries/frameworks you use?': 'Web3.js\nHistory:\nInitially, it was built by Jeffrey Wilke.\nThen Marek was working on it. Then I joined.\nAfter Marek left, I took over. I’ve been on it on my own for the last and a half year.\nDid a full refactor. I changed everything to be more intuitive, simple, how I thought it should be.\nChanged to a Pub/Sub model – can currently subscribe for logs, transactions, block headers. In the future, you should be able to subscribe to state changes, account balance changes, or anything else.\nIt’s harder now to make global changes across Ethereum – because of different clients, agreements take time\nE.g. Parity has the Pub/Sub model, and a parity-Pub/Sub model.\nA lot of work around promises resolving based on conditions\nBetter documentation.\nAccount generation, key generation, signing, …\nABI Encoding, decoding, all are exposed.\nGoing forward: the API is good now, so someone should simplify the internals.\ne.g. scrypt package is super large.\nWe hired a new person who starts in July.\nThe security model: either the person developing web3 is trusted, or you need a lot of people looking at it.\nWould love to at some point decentralize & bountify the project.\nThe project doesn’t need too many more people. The main work is done, but future addition could take more work.\nThere are two groups around the identity profile now:\nPut it off-chain: for privacy etc.\nPut it on-chain: ERC725.',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '28': {
        'Name': 'Hudson Jameson',
        'How do you handle smart contract verification and security?': 'Use the Remix tool to just scan for general bugs.\nWanted to use Oyente, but don’t know how to use it\nRemix is thinking about being modular to the point where you can just plug in your own about module - that would be awesome to see.',
        'Other bounties?': 'Dev Grants from the Foundation\nEthereum foundation had 2 iterations of this program\nGet some money to build something at the protocol-level\nThe foundation is looking into revising the process.',
        'Who are you and what are you working on?': 'Mainly focused on solidity smart contracts. A little node JS and Java but not very good at it.',
        'What are the tools/libraries/frameworks you use?': 'Remix, MyEtherWallet, MetaMask',
        'What are your biggest frustrations?': 'Hard to read error messages. Solidity and EVM might fix this with error messages.\nAre you running into problems with any of the following:\nGas limit: Totally. If you don’t properly separate your contracts or import too many, the gas limit blocks you. Especially on Ropsten with a dynamic gas limit, this doesn’t work.\nOff-chain computation: Many things can’t be done until TrueBit becomes a real thing. Biggest one being stuff like Plasma and side chains aren’t possible until TrueBit is ready.\nState Channels: Haven’t worked with them personally but understand them and think they’re cool.',
        'How do you handle testing?': 'Have been using Truffle more lately but was mostly just using Remix before.\nWrite the contracts in Remix, deploy them in Remix. Usually do it all through Remix and MetaMask. Used to connect metamask to a ropsten node run locally, but now metamask is more reliable.',
        'What tools don’t exist at the moment?': 'Remix combines an editor with a deployment mechanism and that’s what I like about it.\nEthMix was like a full IDE with better syntax highlighting and better debugging. And it was a native app instead of web-based. Pity that it has not been maintained.\nSomething that automatically uploads the contract to ENS.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'The resources are pretty spread out, and everything moves so fast it’s hard to keep up today. If you’re using resources from 6 months ago they might be wildly out of date.\nAndreas Olafson had the only videos and tutorials on solidity, so I just watched those to learn.',
        'What are you most excited about in the short term?': 'Casper. It’s already kind of going into testing.\nTrueBit near the top of the list because it has so much potential.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Raine Revere from ShapeShift',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '29': {
        'Name': 'Martin Swende',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'I was a security professional, doing consulting, came into Ethereum a couple of years ago solving bounties for VMs.\nOctober 2016 - became Head of Security at The Foundation.\nMonitoring mainnet.\nBeing able to react when there is a consensus flaw. Had an API call to geth, called getBadBlocks. Geth will save bad blocks and you can query node for it.\nSo, we run geth and parity simultaneously. Ask parity node for last block, ask geth for bad blocks, If they match, can see more easily why and who might have acted badly.\nBut can’t do it vice versa - been nagging Parity to add that end point so we can do the same process in reverse.\nGeth client has a lot of metrics: how many i/o connections, db writes, block processing times, peer connects. Can export from geth and display in any charting you like. So, that’s exactly what we do; get nice graphs about tx churn, how txes were rejected, queued, pooled.\nOptimizations in geth which made block processing faster in the past month. You can also monitor for performance, not just security...\nShanghai attacks taught us that performance very much related to security.\nP2P network information, protocol dissector / analyzer -- if I can see what is happening on my node and what my peer capabilities are, what have they seen, etc.  Is there any one peer that is sending me transactions that I reject? That way, I can identify bad behaving or lying peers (more in-depth view of what people are telling me over the network)\nWould be difficult as an add-on (need node keys, decrypt data, etc.),  Much simpler to do within a client.  Protocol layer in Geth.\nBuild tools for analysis, especially when things are going wrong: hacks, network problems.\nE.g. transaction propagation when network was overloaded with txes going back & forth between parity and Geth.\nNeeds for lots of testing around hard forks as the existing tools were not sufficient to cover all cases.\nCoverage guided fuzzing - generate code and run on instrumented version of Geth / Parity. This matches code coverage, generates new code and increases coverage using fuzz tactics to mutate inputs and can test geth and parity differentially. Do they have the exact same stuff in the stack, in memory etc.?\nAnother fuzz testing tool based on EVM Lab that can generate tests for CPP ethereum and can cover py-ethereum etc by running in docker container with a switch that enables an output after every opcode and compare internal state differentially again. Run this 24/7.\nCaught 5-6 consensus issues with this. Last hard fork was a controversy as Parity had done a whole bunch of releases prior to the hardfork and the suggestion was to postpone, which would have caused its own issues and forced clients to update again.\nIf patched before hard fork - no problem. Beat the drums and tell everyone to upgrade.\nIf you find a consensus issue on an existing client it is a bit more problematic.Telling everyone means giving people the chance to exploit it - tough to handle.\nExamples of consensus issues: make a tx which invokes a precompile like verify_signature and if that, in one case returns true and in another returns false, or if they cost different amounts of gas (i.e. x on geth and y on parity) then post-state will be different so they won’t accept the same blocks and then we have a fork.\nThere was a consensus issue that happened after Spurious Dragon when we implemented state cleaning. Chain split for 200 blocks, which were created on the wrong chain that were then abandoned. Block 2 600 000 or so.\nDevelopers need to be alerted as soon as possible so they can fix it ASAP. People can lose money in the meantime, txes can be reverted. All exchanges need to be alerted to hold deposits and withdrawals.\nHave built tools to detect this, so we consider it solved from a technical p.o.v.\nRecommend that exchanges run all clients, but not sure if they do. Could be standardised with docker containers that could be more streamlined. Documentation around best practices, automated tooling etc.\nBuild
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Definitely a need for more developers, either full time or for some scoped project. And not just people wanting to work on ethereum-js!!\nProper debugger would be easy enough to scope out. Built into geth VM, a standardised debugger with hooks so that it can be hooked to FireFox debugger etc.\nNetwork visualisation analysis tool is also very NB.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '30': {
        'Name': 'Kevin Owocki',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Gitcoin X EthPrize\nMore talent than fundable issues right now at Gitcoin - always looking for more cool stuff for the community to work on.\nHappy to help.',
        'Who are you and what are you working on?': 'I developed Gitcoin, a bounty (and tips) platform for incentivizing open source contributions.\nSolve incentivisation problem of OSS, where it is highly strategically valuable but difficult to capture in real-time the value being created.\nI want to bring more devs into the space - MAIN GOAL.\n300 bounties fulfilled so far and recruiting opportunities for OSS developers\nConsensys offered customers (projects creating bounties for pilot of gitcoin), funding, regulatory protection\nNot totally interoperable for now with EthPrize, recruiting strategy etc. Bounties are just one of the tools to recruit developers',
        'What are the tools/libraries/frameworks you use?': 'Truffle for managing deployments and smart contract versioning\nWeb3Py, due to comfort with py and personal relationship\nDjango, Bootstrap, Metamask, Infura for Gitcoin Platform - which is mostly a standard web interface.',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Pytests with TravisCi\nUsing product. Use gitcoin to build gitcoin.\nSelenium tests with native web3 functionality',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Onboarding users with first time Dapp user experience like metamask, mainet/testnet really sucks and could be improved in a number of ways.\nWe started off chain, since standard bounties is not something we wanted user to pay gas for\nWhat we’d like to do on-chain\nStart work feature signal in off-chain DB\nWould be stored on-chain\nStaking process for starting work on a particular bounty\nWhat features from web dev background are lacking with Dapp Development?\nWe’ve struggled with managing gas fees on behalf of users\nBuilt gitcoin.co/gas for scraping EthGasStation for least amount of gas + low confirmation time.\nWould be nice to visually see gas price vs confirmation time.\nWould’ve been nice to integrate gas manager with block explorer, more dapp UI’s\nEasy javascript widget to take place of metamask to not hinder gitcoin developers by requiring chrome download. Web2 payments to Web3 payments bridge to abstract away the harder blockchain concepts. Maybe an e-commerce-like widget for paying for gas via CC.\nPortis might be like this?\nStablecoins and improved UI’s\nSelenium integration tests with native web3 functionality\nYou can work with DOM on Selenium but you can’t hookup chrome extension (Metamask)\nMight be possible with JS widgets\nhttps://github.com/ethereum/EIPs/issues/948 Subscriptions on the blockchain would be great',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Below links, youtube videos\nhttps://gitcoin.co/help\nhttps://www.youtube.com/watch?v=cZZMDOrIo2k\n https://github.com/gitcoinco/gitcoinco/issues/38\nGeneral help content writing',
        'Are there any other questions we should be asking?': null
    },
    '31': {
        'Name': 'Quazia & RJ',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'A solid debugger – needs a rare breed of dev to build.\nScaffolding tool for prototyping things –\nTo test a small contract before integrating with everything else.\nThink this will standardize over time.',
        'Who are you and what are you working on?': 'Giveth - Charity platform with three layers\nFairly complex contracts on-chain. Pushes the limits of gas limit. Making transactions is relatively expensive.\nOff-chain stuff. We cache everything; we store images and profiles offchain, will eventually be on IPFS.\nSome actions are not on-chain: “reviewing a milestone”.',
        'What are the tools/libraries/frameworks you use?': 'Remix vs. your local dev environment:\nCan write code, deploy, and debug in Remix.\nEVM Lab: written by Martin Swende; give it a tx hash; spits out opcodes, storage, memory.\nRJ wrote source code mapping – doesn’t work for complex contracts. Show your contract code along with the opcodes.\nWe use it often. Simple CLI tools. Just need Web3 and a tx hash. Sounds AMAZING.\nTo be improved: bugs with reproducing certain transactions.\nE.g. couldn’t recreate contract creations.\nSource mappings.',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Offchain stuff is not dispute related.\nGas limit issues:\nJordi wrote contracts to begin with – so WE had a good start.\nMultiple DELEGATE calls to the same contract are the same price each time; but this doesn’t make sense. You’ve already loaded the contract in memory, so should be cheaper in consequent calls.\nAbstracting – one key-value contract that stores pointers to data.\nRest of data – stores all data. Mappings of hashes to boolean to structs / addresses / etc.\nLeads to upgradability of contracts. To the parameters used in the logic.\nSeparate data from the application; let’s you iterate. The data contract is owned by the business logic, ETC.\nEstimating gas / optimizing code:\nTo get gas limit: run it on testrpc. Easy.\nDebugging is hard, after you start adding assembly in there.\nRemix is hard for large contracts. Multiple contracts.\nTesting flow:\nWe use Mocha + wrappers to generate contracts in Js.\nNeeded: better errors. e.g. if testrpc spit out more useful messages.\nDeployment & CI:\nWe have Node scripts to do this. Async await. Pretty simple contract.\nJordi’s tool compiles everything into a single file; makes verification on Etherscan simpler.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '32': {
        'Name': 'Griff Green',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Scaling proof-of-authority.\nBlock explorer.\nRopsten testnet gas limit -> attacking with gas limit.\nOpen-ended: apply for a bounty with your own idea.\nWe need a 24/7 security team. The network is not being watched by anyone; because right now the network is being attacked in a weird way, through the estimate gas function and throwing txs in pools.',
        'Who are you and what are you working on?': '3-tiered approach:\nBlockchain smart contracts: liquid pledging; pledges that take control of authority and funds. Blockchain layer does the accounting.\nOwner gets notified by email.\nBounty system: basically a chat room. Project discovery layer.\nUI layer: reads off the blockchain, interacts with the blockchain.',
        'What are the tools/libraries/frameworks you use?': 'Use Feathers interface to do caching. Improves UX.\nNPM. Etherscan. Metamask.\nSet of tools that we made ourselves. We don’t use truffle because we were building smart contracts before truffle was a thing.\nReact. Remix.',
        'What are your biggest frustrations?': 'Irregularity of gas price.\nKey management - hands down stopping adoption. Need more people teaching about key management. Tutorial materials? Bounty?\nRopsten testnet gas limit.',
        'How do you handle testing?': 'We lean on the community a lot and give them “sneak previews”. We let them to go through the UX, and watch what happens.\nThe same person does all the testing.\nWe do a lot of auditing for other projects. Audria does this. We have a lot of good auditors and always maintain 100% code coverage.\nUse travis for CI.\nMost bugs they see are about game theory & cryptoeconomics.\nThese come up in ad-hoc situations.\nWe try to isolate things into individuals. Clear interfaces.\nWe always wanted push to live mainnet right away, but...\nToday we made the decision to go to testnet, because mainnet is so expensive.\nTestnet is not real a test (since it’s not real money).\nWe’re going to have a testnet token that represents real Ether.\n“Proof of Authority” using Rinkeby.\nUsing the Minime token controller. Multisig pays out based on what’s happening on testnet.\nEhter’s price has gone up, gas is high, so everything is super expensive.\nBAD for our users.\nThis is game over for dApp developers.\nIf Ethereum cannot solve these issues, developers will leave.\nRSA, Ubiq will have Solidity. But don’t have block explorers. White hat hacker group is looking into\nOpen-source Etherscan.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'What was the first thing you built related to Ethereum?\nBuilt a Will contract. Got a Masters degree in Digital Currency.\nAlex van de Sande took the time to correct his code on Reddit.\nTalking about price makes people act like assholes.\nThe DAO!!',
        'What was the hardest part about learning to develop with Ethereum?': 'Lack of sharing and communication. I know other people are using React, building UI and that we could re-use that.\nHow to go from web3 to the UI. Could do more research to re-use existing open-source tooling.\nIn the beginning we were purely running on the blockchain as a db. Then, their UX suffered due to slowness. Feathers helps alleviates this.\nWe are a holocratic org. We work in small teams, building the GivEth Galaxy.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Taylor and Hendry from myetherwallet\nDave Appleton\nJack from Colony\nDistrict0x crew\nSwarm City - Bernd Lapp\nKhosla\nNick Johnson\nJorge Izquierdo\nJordi Baylina\n Phil Dian\n Matthew Diafrante\n Karl Floersch\n Emin Gun Surrer\n MakerDAO - Andy\n David Knott - Plasma',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'What other projects do you interact with the most? Building the Ethereum topology, who works with who and which projects? Where there are chasms, so you can get bridge them.  Maybe a bounty?\nThere’s so much good stuff on people’s githubs.\nHow do you know where to find stuff.\n“Sort all Ethereum projects that are using React” -- aggregation of data. How can we get this data into searchable formats?'
    },
    '33': {
        'Name': 'Jordi Baylina',
        'How do you handle smart contract verification and security?': 'It’s important to communicate to everyone that whatever you do will help, but will never give a warranty that there won’t be an error.\nI’m a bit skeptical of formal verification stuff, but I think it’s important to keep pushing it forward.\nDo more audits.\nWrite defensive code. Don’t try to do crazy things.\nFor the first time, we’re mixing two things that haven’t been mixed together:\nThe two:\nCritical code – contracts holds money.\nOpen-source – everyone can see how it works.\nE.g. you don’t have this in planes – critical program but not open-source.\nE.g. in a website – it could be open-source but not critical.\nSo you realize you need to write perfect code, but that’s not possible. Because code is written by humans.\nIt’s important to improve:\nDo not take risks.\nTry to isolate the critical part. E.g. if you’re doing an ICO, don’t hold the ETH in the contract, instead put it directly into the multisig.\nMinimize the box, with its known security vectors.\nOn one side, you have a blockchain that by definition that is immutable. On the other side, immutable is not compatible with making mistakes.\nHumans make mistakes. We are building things on top of that immutable base that could have mistakes.\nBut we need to keep blockchains immutable, because if don’t, we lose their power.\nHow do we solve this?\nPossible approach is having a second layer –– instead of ETH, we use an ETHToken. ETHToken has governance built in and can be modified. You build it in a more centralized manner, it can be changed; and then overtime, you soften the centralization rules, and make it decentralized (take away the authority, make it operated by a DAO, etc).\nE.g. having an escape hatch would be super helpful. If there is a hack, it could be sent to the EF or whitehat group. And then you can decide what to do. Better than it going directly to a hacker.\nAnd then you can build the smart contract applications on this second layer.\nWant to make decentralization linear; so you don’t have to take the risks from the beginning.\nAll contracts in Giveth have escape hatches built in.\nSTANDARD LIBRARY for using ETHToken in your contract, layer for security, escape hatches => I think it might be a bit too early though since we’re still figuring it all out. Other teams working on this include Zeppelin, Aragon.\nBetter compilers. Better testers. Better formal verification. All the tooling helps.\nThere are some errors that are not due to programming – they’re conceptual, due to economics, etc.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Experience: 35 years of programming; 3 years in blockchains.\nLearning more everyday; exciting from a global perspective.\nThis tech can change society over time. We’ll see centralised power disappear, the world will become more trustless, people will take responsibility for themselves.\nOne of my first smart contracts was liquid democracy for the DAO.\nSmart contracts for the white-hat group that originated from the DAO.\nWrote the Minime contract – maybe not the best time now because of gas costs, but it is an interesting smart contract.\nDid the Status ICO.\nLiquid pledging for Giveth.\nPushing DappNode - should be released soon and is really important for true decentralization.\nAudits – for MakerDao and Aragon.\n777 standard.\nWorking a lot on an identity project.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Debugger\nThe debugger is still hard –– you have to learn crazy tricks to be able to do it faster.\nReturn codes\nWhen a function reverts, you want to know why it reverted.\nCode coverage\nTruffle has something, but it’s specific to truffle.\nI’d like these tools to be more generic.\nTruffle that works for larger projects\nAcross multiple repositories. You want the contract repo to be able to publish it’s interface, and another repo can use that to interact with it, etc.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Where do you think improvements can be made?\nbefore we can really go mainstream:\nScalability.\nSecurity.\nUsability\nSeems like security is as much an education problem, as tooling. Any ideas how we should approach this?\nDocumentation helps.\nRealize that you will spend proportion of 40-to-1 on testing/auditing your contract vs writing.\nTeam audits\nDoing an audit within your team.\nOnce you’ve done your personal work on the smart contract, and you’ve done your own audit; then get together with your team, and start talking about your concerns, and you’ll see that one idea leads to another, and you discover issues.\nAudits\nWrite some small bugs in the code, and see if the code reviewers find that bug.\nEven if the auditor knows that there are bugs, they will be forced to go deeper into the code.\nBug bounties.\nI was skeptical of these at first. Why would people review this code?\nBut I have seen personally over the last year that big security holes have been discovered in bug bounties.\nBug bounties force you to write very good code.\nYou need to choose the right names for variables, document it, it needs to be understandable.\nGood resource: Consensys, on the history of all bugs. https://github.com/ConsenSys/smart-contract-best-practices\nThis wiki could be complemented with these more generic ideas – around bug bounties, reference smart contracts etc.\nMaybe even write a book around it. An open-source book.\nSmart contract developers could do an annual event – to categorize all the new bugs, new patterns – and consolidate them into the knowledge base.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '34': {
        'Name': 'Stefan George',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Bounties are great for small problems, but we need to hire people full time to actually work on this stuff constantly and fix the long term incentives!!\nJust waiting for the Ethereum Query Language ;) :p',
        'Who are you and what are you working on?': 'CTO of Gnosis and is building a prediction market, ddex and smart contract wallets.\nStarted in 2013 - discovered that we could add prediction markets using btc escrow because that was missing (a p2p marketplace for predictions).\nJoe Lubin convinced us in 2015 to start a formal platform based on Ethereum, did the token launch and spun out of Consensus and begin working on the more fundamental problems\nDecentralized exchanges!! But not efficient on Ethereum today (scalability and number of participants). We have had to contribute to building the DDEX infrastructure.\nPrediction markets are a way to create new ERC20 tokens (conditional payment/purchase). The value of those tokens is only defined at a certain point in the future. We can therefore create derivatives of other ERC20 tokens, which are more precise investments under certain conditions.\nDDEX allows people to trade the efficiently. It can be done in Ethereum on chain, but scalability, front-running and ease of use just isn’t there yet (need everyone participating and having a global liquidity pool).\nDutch exchange implemented on chain to solve front running problems.\nIntegrating with USD price feed of Maker - was a little hard to depend on other people’s infrastructure and therefore the tests that they have deployed. We ended up mocking their service for test net, would have been awesome to just point at their package, specify a contract on either network and go without having to mock any of the other services.\nMake sure that things like ETHPM are deployed across all test networks.\nAlso built the multisig wallet for our own token launch, has been very successful and we now want to offer the same experience for every user: more secure wallets for personal use that are even better than hardware wallets.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Secondary indexing of blockchain data!!\nOnly json-rpc calls to retrieve prediction market data would make it impossible for users to see what markets they hold tokens on.\nExpose state changes between blocks in an easy to consume fashion. Right now you apply txes, but you don’t know what effect on the state is immediately. You have to assume that you know, or listen to events.\nBut events shouldn’t even be there as they are just replication of info that is already there on the chain - just make that info more accessible and easy to read and use!!\nState changes between blocks, sort of like a github diff that you can take and use to index in a secondary indexer - that would be really helpful.\nWriting their own indexer specifically for prediction markets. So is Aragon, and even Augur is now doing it.\nMore client developers - too few people working down there in the protocols. Set incentives for improving the stuff - which is why ETHPrize is so important.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'What does the Gnosis stack look like?\nContracts written in solidity\nMany pitfalls, especially for newcomers - need to read documentation 10 times and then sometimes you still don’t get it.\nFor e.g. the low-level stuff like .call() is implemented differently from what you might expect that caused funds to get stuck in multisig contracts.\nThe concept of gas is not that easy to understand and is not transparent.\nIf you use .send() you use minimum amount of gas versus .call() using all the gas.\nVerification of code and garbage handling is not well documented - verifying down in the byte code is very difficult.\nParticular problem for symbolic execution and all the additional checks that solidity is doing. Not well optimized at all.\nIf you access a storage variable twice, you will always have to pay twice, rather than optimizing to keep it in memory - very annoying in the end. Means you have to do a lot of gas optimisations yourself which really should be automatic.\nThese kind of issues require domain expertise - why don’t we all put up a $1 million bounty for a new smart contract language/compiler.[a]\nMight be interesting to keep it lower level, something similar to Vyper with the much simpler bytecode and cheaper execution, better verification etc. We cannot have only one smart contract language.\nUsing truffle framework because it is most used framework and want their codebase to be as approachable as possible.\nDebugging is an absolute pain in the ass - even truffle’s debugger is not great. No easy breakpoints, difficult to step through easily, or change variable to run different kinds of tests.\nWould be better to statically typed testing environment - only test framework in JS (python one is not maintained). We need another framework that can go deeper and be more precise.\nWeb3 itself really sucks.\nAPI versioning for ethereum json-rpc stuff. No versioning, no documentation, no proper error codes. Plenty of useful calls that are missing, plenty of calls that exist that no-one uses and it’s just chaos in general. We have to assume what version is running on the user end, so have to assume they are running all kind of different versions.\nEveryone using MetaMask and Infura makes this slightly more hidden.\nI proposed a new json rpc call but geth ahd already implemented it, but it was documented nowhere and Parity hadn’t really thought of doing it at the time, so there is no clear way of defining what the standard is.\nWas about allowing users to sign offline transactions in a specific way: ask the client to sign and return the tx data that can be then used from an offline location.\nWe need a test suite against the json-rpc API: just to test that Geth and Parity are actually behaving in the same way.\nUsing Remix IDE - then go to local text editors for further dev once they are sure the contracts run well.\nWould be amazing to have a properly integrated environment. Uses Atom with solidity linter. Would be great to be able to do proper debugging in that environment as well. Things work now because complexity is relatively small - but as soon as you want to integrate between projects it becomes a total mess.\nGas metering and fuzz testing in addition to break points, stepping through, and changing variables easily.\nUse Mythril to check smart contract security, executions and test coverage. Aim for 100% code coverage and use solc code coverage.\nWould love a tool with some basic checks (like overflows etc), but needs to be extended to do optimisations for gas efficiency, standard way to apply smart contract best practices automatically.\nMap test coverage to code execution paths so that you can easily see which cases to write tests for. Something better than code coverage which only shows where you touch the line so that we can cover the most important scenarios (i.e. where things are failing).',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '35': {
        'Name': 'Alex Leverington',
        'How do you handle smart contract verification and security?': 'It would be nice if some of the audits were completely opened up – rather than some statement from the auditors. Could be a security issue.\nWhat we have right now for audits can be improved upon with better tools.\nAudits and testing framework go hand in hand.\nAuditor should be able to write a test to demonstrate the problem at the EVM level.\nInstead of the auditor suggesting some workaround or wrapper.\nOr auditor provides proof for something that works well.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Can’t say what I’ve working on in a concrete way, but I am building a team and starting a new project.\nI’m advising some projects.\nDid some original stuff on the P2P system.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Haven’t come across any tools for game-theoretical stuff.\nFor code: using scripts for testing.\nIdeally there would be a testing env that can do “introspection” & which can evaluate the state of the memory. It should test the effect of code rather than the output of the code and make sure that the tests all integrate with Solidity.\nIt’s really hard to write unit test for the EVM state, as a result of some code executing. It would be good to have a test for this[a].\nWill be looking at tools in the next two weeks.\nHaving a tool which exposes the EVM state – for this you need some code that understands how Solidity stores data in the EVM.\nFor looking at EVM state:\nRemix is ok.\nAleph0?! Doesn’t exist any more.\nSome cases where your code doesn’t change, but the environment around your code changes –– having actual tests.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Debugging Solidity and EVM\nRobust distributed system for content delivery.\nSwarm and IPFS are both in Proof-of-Concept form.\nIPFS is minimally viable when you use gateways. But there’s potential for improvement\nI haven’t used either in a while –– but my understanding is:\nSwarm is a little slow\nIPFS is ok –– but you need the client software to run multiple p2p nodes.\nAll the demonstrations use HTTP gateways –– there aren’t tools and packaging for having production software on the p2p protocol.\nIntegration should be in the offchain code.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Ambisafe - Olekseii.\nLunyr - they’ve been kind’ve ahead of the curve in implementing things.\nI advise them.\nThey & cryptokitties have production code on mainnet.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '36': {
        'Name': 'Alex Miller',
        'How do you handle smart contract verification and security?': 'Hasn’t had any novel code that needed security audits before\nThere are common patterns that could be detected. E.g. reentrancy attacks, etc',
        'Other bounties?': 'Collecting logs & events used to be hard. Web3 1.0 made this a lot easier. It is quite good, even-though it’s in beta.\nPeople should be using websocket calls more. Maybe more education around this. Serious efficiency gains to be had here.',
        'Who are you and what are you working on?': 'Started ETH development back in 2015. Shortly after launch; there was nothing. I remember booting up private chains from shell scripts. We’ve come a long way in terms of dev tools. Problem isn’t that there aren’t tools, but not knowing where to look.\nThe problem here is sourcing a centralized repository for information[a][b].\nEF website doesn’t do that.\nWouldn’t know where to point people from intro documentation.\nTruffle & Solidity have good docs e.g.',
        'What are the tools/libraries/frameworks you use?': 'Truffle\nConfigure parity instance https://github.com/GridPlus/trustless-relay/blob/master/parity/boot.js\nInfrastructure tool to spin up local instances of Parity or Geth',
        'What are your biggest frustrations?': 'Biggest pain points: a place where all these tools get published that isn’t just Github.\nIs the solution to hire / pay people to manage a wiki?\nMaybe a better solution would be to fork NpmJS.com, source that data, curate that list for Ethereum dev tools\nWould check that deployment to node packages happened & EthereumPM setup correctly.\nCan see how many people have downloaded. It’s a good method of discovery.\nCould have different subsections e.g. Merkle tools, hashing tools, ABI encoders.\nI use Ethereumjs-util – but I know there are others.\nWhat about EthPM?\nIt’s only on Ropsten. What is the link between EthPM and the actual blockchain? I like that there is an actual package manager. Good thing is that you can install packages with Truffle.\nI don’t get where the data is stored –– is it on IPFS? Is it linked to Ropsten? Why?!\nStill, it’s great. But recently it stopped working.\nI wanted to deploy a trustless-relay – but had issues.\nCould make one of these Awesome-Ethereum Github repos?\nAlso knowing what you need to discover is important: wiki would help here.',
        'How do you handle testing?': 'Use Mocha; plain old truffle tests.\nI don’t do contract unit tests.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Truffle\nThe fact that you don’t really get errors, or more specifically stack traces. Whenever you run into an error, it gives you a line number[c].\nIn JS files.\nHow to match up hashes of data with what you get in Solidity.\ne.g. When you’re tightly packing arguments, they need to be left-padded to 32 bytes. But not always, e.g. different for addresses and numbers.\nA little app like this for Solidity would be amazing, which gives you all the Solidity hashes: https://emn178.github.io/online-tools/md4.html\nEmulate what’s happening in Solidity in the browser.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Sean Pollock.\nMark Beylin.\nGoncalo (from Consensys audit) -> has a great library for dealing with bytes (byteslib).',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '37': {
        'Name': 'Dave Appleton',
        'How do you handle smart contract verification and security?': 'Helps that I’ve been coding for a helluva long time.\nThe hardest thing for new devs is getting to contact the people they need.\nIt’s also hard to find non-expensive auditors.\nGitter community is the key\nBest dev communities or Gitter channels:\nGo-ethereum\nSolidity\nParity\nI go to the specific one I need at the time.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Lead blockchain dev @ HelloGold.\nToken backed by gold.\nDoes consulting as well – writing smart contracts & backend for blockchain projects',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'About a year ago, it was ok running blockchain on your machine.\nSwitched from geth ropsten to Parity.\nIt’s hard to run a Parity node now – the toll it takes on your machine.\nBoth on mainnet and testnet.\nYou can’t do serious stuff with Infura:\ne.g. getting events reliably\nIn Geth or Parity you can do some event filtering, but is tough to get right and maintain\nInfura limits the number of logging or block calls -> to limit server complexity or costs.\nDebugger\nEthercamp\nPromote hackathons.\nEthereum Studio - what happened to it?\nGave you break points in Solidity code (?!)\nYou’re running in a simulated VM. You’re in your own dev environment.\nLet you see all the state and local variables & methods\nCame up with a node that EF took over and turned into EthereumJ\nEthercamp code is open-source -> Look into this…\nI use Remix for prototyping something.\nWill probably be a niche product.. Because not many developers are getting that low level.\nWeb3.js is another pain point:\nGetting up to speed trying to do Web3.js is quite hard. There’s a lot of conflicting information. The examples don’t work. This is where you find that the node you’re using doesn’t support features.\nGo-ethereum wrapper: abigen. This is my favorite tool.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Programming languages: Go\nCompiled program with strong type checking, before the code even runs.\nEnforces code standards, meaning your code is maintainable.\nThe linter formats the code in a certain way. This makes it very easy to understand.\nI choose readability over speed; Go over Rust.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Talk to Andreas to get to people in Singapore.\nRick Bale @ The team at Endorse.io\nOr also talk to the CTO.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '38': {
        'Name': 'Peter Kieltyka',
        'How do you handle smart contract verification and security?': 'Obviously security audits, looking through network and past experienced colleagues. Don’t see us using formal verification unless that process is made easy, but I don’t think that will happen. We will stick to security audits. Thoughtful in how things fit together and are secure.',
        'Other bounties?': 'Gas profiler 100%.\nWould love to see an Ethereum Virtual Machine written in JavaScript. The Ethereum JS VM written but it’s a little bit bulky. Important to offchain application, important for state channel applications. Richard Moore is writing this.',
        'Who are you and what are you working on?': 'Started Horizon Blockchain games, building decentralized multiplayer games. What we’re excited about is a new class of video games, in which players truly own in game items. Own them, and can trade them. They can even compete cryptographically to earn/unlock new items.\nOne of the core areas of work that is started immediately: how can we make high fidelity games that are scalable, low-cost, and provably fair. Video games with a decentralized economy. Can mine new items as part of the economy.\nLove building new models on blockchain. What is most excited to do is to create utility through video games via blockchain.',
        'What are the tools/libraries/frameworks you use?': 'We’ve built a blockchain gaming architecture with a low fungibility token, similar to ERC 721. We built our own state channels. We’ve also created offchain game logic, and can verify the game in a single state. Skyweaver.net was our very first game. All work will be open source, won’t do an ICO.\nGame is offchain, persist the awards on chain. Based on a finite state design.\nUse Truffle, Ganache-cli, write the infrastructure in Go. Geth is written in Go, that’s very nice.\nClient side application, standardize on Ethers.js (Richard Moore). Without Metamask you lack adoption. Ethers.js is being ported to Typescript, excited about that!\nWeb3.js has a lot of dependencies, large in filesize, and the API is not as compelling as Ethers or productive. Just too bloaty. Was great that it exists, but want very very lean tools. Ethers is just so active and very tight. Following newest standards and practices. Back the guy with the deepest knowledge.\nTruffle is really cool. Helps with Developer workflow, but we spin up own testRPC service with Ganache. Truffle helps with deployment of contracts as well as package management. Truffle is now a monorepo, I pushed them to become a monorepo.',
        'What are your biggest frustrations?': 'Need more example of really great dApps, more high quality examples. Zeppelin is doing a great job of making a standard library, but more interested in end-to-end. Don’t know of great examples of these high quality dApps.\nScalability is super important, when state channels and plasma channels arrive the whole game changes. Want to see good convergence in state channels, need off-chain computation. Want to see good collaboration here.\nFocus more on end-user. Improve onboarding to Crypto.\nWhen people think about scalability, people think about throughput and performance. But cost is integral to this. But what is the transaction cost. Optimizing for cost is a form of scalability.',
        'How do you handle testing?': 'Do it in Typescript with Ethers.js and Chai and Mocha. Use Remix Solidity IDE. Amazing IDE for testing little blocks of code. Testing would be another great things to see more examples of Ethers.js',
        'What tools don’t exist at the moment?': 'Profiler at ETHDenver, to see gas costs.\neWasm will be game changing. Potential for having other languages target the EVM will create a more productive developer experience.\nVyper will be great. Their goals are twofold, improved security through usage of the language. Learning from Solidity. Security + productivity.\nReally happy with seeing progression of Solidity. As cool as ewasm is, who knows when it will be ready.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Wrapping your head around the architecture. Very multidisciplinary. And the tooling is in flux. Lack of examples. Architectural issues. Costs are fundamental thing.\nEthereum coding is really like developing for an embedded system with little memory, storage, and cpu power. Unfortunately don\'t encourage beginner to be writing this stuff. But getting better.\nTry to map existing architectures to existing things that people knew about. Realizing how everything fits.',
        'What are you most excited about in the short term?': 'Blockchain video games.\nVery excited about Casper+sharding. The team is doing incredible work.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Richard Moore,\nCTO of Dencentraland. Esteban Ordano. Great guy, very knowledgeable.\nLiam Horn, should pick his brain. Very hands on in Solidity.',
        'What are the best educational resources?': 'Point them at Blockgeeks, all about Blockchain development education on Ethereum. Plus searching Twitter and Github, look for those great open source dApps out there. Look for examples of end-to-end dApps\nCryptoZombies created a rad Ethereum tutorial.',
        'Are there any other questions we should be asking?': 'AwesomeList, community curated high quality tools. Ethereum website needs to be completely redone. Here are the awesome projects, here are the awesome tools, here’s how to get started. Same with website work.\nExactly Ethereum Foundations problem, do not want to make any opinions that aren’t in community consensus. People voting for what they want worked on. People can vote on things. Certain weight to reputation. Consensus machine to conduct this type of thing.\nWith a footnote, don’t need to perfect this system. Don’t need a perfect design to start.'
    },
    '39': {
        'Name': 'James Prestwich',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Simple contracts to manage cross-chain swaps and contracts.',
        'What are the tools/libraries/frameworks you use?': 'Python ETH Library - ABI Parsing expects events to be in two different formats neither of which you expect - ecosystem standardizes on hex strings\nRLP is a hot mess - why use a non-standard serialization format for everything\nEnsures nobody understands what’s going on and things aren’t readable - serialization format for everything ETH - includes transaction data\nAs a human - can’t reason very well about those blobs or what those structures will have\nDeveloping contracts on Bitcoin first - Solidity, Script, Snark tidbits, IVY (compiles to bitcoin script)',
        'What are your biggest frustrations?': 'Solidity is the wrong tool. Imperative language and everything on blockchain is declarative. Solidity should be declarative.\nIVY is best example of for blockchain language. On blockchain control logic is impossible: blockchain never decides how or when a function is called. No such thing as on-chain control logic: off-chain controls how humans can manipulate state.\nAll lies: completely wrong tool for blockchain. This is what causes render mistakes: trying to write on-chain what happens, but should be defining what can/can not happen (Bitcoin: whether you can or cannot spend a UTXO).\nRequire statements example of Solidity becoming declarative language is not a good way to fix this and modifiers are an anti-pattern:\nEither happens as atomic single unit at will of human or it doesn’t?\nConfigurable constraints on-chain: we should still define them as constraints -- no math happens on-chain (not actually adding 2+2 on chain).\nWeird that tests are control logic for your code. Control logic is whether human makes a transaction.\nIdea that we are writing things that add variables on-chain is wrong.\nReality of state, state root and blockheader is what causes a lot of the bugs\nIVY: really heavy modification to write on ETH -- more easy to write languages for the EVM. A declarative language for EVM. Tooling for Solidity only recently got workable.\nOnchain systems should define constraints around what cser can / cannot do -- they are the control logic of the program.\nCross chain contracts for integral is what users can and cannot do at what time and on what chain (declarative programming again).\nChecks, Effect, Interactions to write code. We need more good programming to prevent race conditions, re-entrancy, double spend etc:\nTransactions happen atomically, cant have overlap in state changes\nCan shoe horn ETH into this by using Require / IF Statements (??)\nAvoid modifiers as a pattern\nThat’s always the effect of the Solidity you’re writing - puts more pressure on the client\nMakes testing more intuitive -- specified tests you’re testing against\nVery interesting miner attack on EtherDelta: they front-run; make tx throw; collect the fees.\nThe problem with Solidity isn’t expressiveness; it is shared state. Other transactions can get ahead of you and modify state that you rely on.',
        'How do you handle testing?': 'Wrote tests with James on Integral stuff',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Proof of Stake\nGetting someone slashed decreases supply, increasing value of ETH. Does this mean every ETH holder is incentivized to getting stakers slashed?\nIn the Blockchain/cryptography in general, there is attack-defense asymmetry with defence being stronger. As soon as you move towards servers, attack-defence asymmetry leans towards the attacker.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Did all the Ethereum tutorials -- set up the token\nIntegral: written in Solidity with Truffle -- derivatives platform',
        'Are there any other questions we should be asking?': null
    },
    '40': {
        'Name': 'João Gabriel Carvalho',
        'How do you handle smart contract verification and security?': 'Every project I’ve done will go through an external audit. As a developer, usually run Mythril and Remix (uses Oyente?). But these only find basic bugs, are years away from more complex stuff. These are just the most basic checks.\nFor Auditing, use a lot of Remix with manual testing as opposed to JavaScript tests. This is easier and less fake.\nThe harder thing is flattening files. People use OpenZeppelin, other frameworks. Have to go through a lot of different files to understand the logic. Tool to make understanding this easier.',
        'Other bounties?': 'A really good IDE.Not a plug-in, but a full IDE. Best elements of Truffle, best elements of Remix. Could connect to Geth. More refined deployment options. Make compiling easy, knowing the gas prices easier. Debugging, deploying. Everything in one place.',
        'Who are you and what are you working on?': 'Contributed to OpenZeppelin and Aragon about 1.5 years ago, met an audit company called Solidify. Worked with them as a developer, and also have done a lot of audits securing smart contracts, now back to development. Things happening that will be public soon, stay tuned!',
        'What are the tools/libraries/frameworks you use?': 'Truffle.\nUsed a little bit of Embark but not a ton.\nUse Mythril, Remix, TestRPC -> Ganache, Geth, also used a few Solidity flatteners.\nInfura.\nWeb3.js.',
        'What are your biggest frustrations?': 'A really good IDE. The integration between Truffle and Remix is not good at all. Remix debugger is better than Truffle but painful to upload a bunch of stuff to Remix just to check. Wish there was a way to integrate both tools.\nA more robust testing framework for Truffle, it’s very basic and dumb if you think about it. A lot of room for improving testing tools.\nThe issue is that I don’t have functions to hit a contract with 1000 transactions, I have to do it manually. Create me 200 tokens and send to this contract and see how it behaves. Tests are small scale. Testing suite at scale could be interesting.\nMore state management in testing. Want to save specific states and fork it and compare it to the fork. A lot easier and automatic.\n10 accounts are provided with 100 ETH. That’s not enough to test an ICO like condition. If he wants to test 100 accounts with 1 million Ether, it’s not easy.',
        'How do you handle testing?': 'Do it manually, 1000 accounts with 1000 Ether. A big loop and keep sending transactions\nDo this multiple times with multiple states. A lot of handwork for not a lot of results.\nLarge scale testing is not really worth it.\nWas testing an interactive ICO, very complicated process. State management was very hard, multiple states at same time. Made a loop to do it manually but was quite difficult.',
        'What tools don’t exist at the moment?': 'Love to see a premium version of Infura. Infura is public nodes. Has to sign tx’s offline, has to sync my own Geth. I wans to have an Infura account. Infura is pretty good here but could be a bit better.\nLacking resources for other languages other than Solidity. Doing anything with any other language, there is not enough material and you can’t find the answers. Creating a gigantic gap between Solidity and other languages. Usually use Solidity because it’s way faster.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Hidden barrier for understanding blockchain in general. Could be a decent developer, but to understand Ethereum you have to understand what is a blockchain, how does it work. And you can’t learn this in a day, there are complicated concepts that you have to learn with time. Have to really know what a blockchain is to develop a contract that makes sense.\nHave to do a lot of handwork that you don’t do in other languages. There are no error messages. Have to comment your code and run it a thousand times to see how it’s failing.',
        'What are you most excited about in the short term?': 'Excited to see where all the scaling is going. Plasma, Casper. Starting to get implemented and finalized, can see demos. That’s awesome.\nExcited for proof of stake. To see how the ecosystem changes.\nInterested to see how average user interacts with Ethereum. UI/UX.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'CryptoZombies is pretty good for a beginner. Capture the Ether is a bit more focused on security and hacks. The best thing to learn more is to read contracts. You can understand a lot of how big projects work and it’s very good for learning.\nOpenZeppelin is a good place to start, has day 1 level stuff. Gnosis has a lot of well-written contracts, a bit more advanced. Same for Aragon, complex but it’s well-done. These are the ones I’m more familiar with.',
        'Are there any other questions we should be asking?': null
    },
    '41': {
        'Name': 'Andreas Wallendahl',
        'How do you handle smart contract verification and security?': 'Also Josh Cassidy',
        'Other bounties?': 'In-browser signing. Would make new user onboarding much, much easier. Metamask works on it but a bounty might drive it through.\nA lot of people have built interaction with IPFS, that’s why we built IPFS-store and eventium.\nBlockchaimulator for testing that runs through 100,000 blocks, somewhat instantly. We had to wait for blocks to be produced.',
        'Who are you and what are you working on?': 'Kauri\nDecentralized knowledge base built on Ethereum and IPFS\nGithub is for code, Kauri is for how to use it. Built in incentivization layer enabled by Ethereum, enables bounties for new content. No token, uses Ether/ERC-20 token.\nMost popular tutorial is new content from Maker.',
        'What are the tools/libraries/frameworks you use?': 'Truffle\nGeth nodes on Google Cloud\nEth.js\nReact',
        'What are your biggest frustrations?': 'Helping a user know what to sign and what it actually means at the blockchain level.\nIf new user comes to your website without Metamask, they can’t interact with any web3 on your page.\nGitcoin uses a faucet to get around this\nOnboarding experience\nMost users are devs so they understand it better than most\nInternal Consensys initiative started to onboard new users',
        'How do you handle testing?': 'Needs to ask teammate (Josh Cassidy)',
        'What tools don’t exist at the moment?': 'Simple spin up of side-chain or scaling solution kind of like Heroku\nSpankcard for counterfactual state channels is a good attempt at this\nOmisego and Plasma team\nRapidly spin up and set criteria for Plasma chain\nGas costs\nIn web signing capability- I could preload Eth or fund with credit card. But, if users are used to this behavior there might be man in the middle attacks.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Hardest part was not knowing where to go in the beginning. Watching videos to understand concepts of blockchain. From there, Truffle and its intro tutorials.\nEveryone was rebuilding the same stuff/components for public apps and enterprise use case.',
        'What are you most excited about in the short term?': 'Anything people can experiment with, and that can prove interest/demand.\nNFT’s, Ujo and Cryptokitties.\nBlockchain’s version of single sign on. Store user information in some way (IPFS or UPort contract)\nHow do we get to 1,000,000 daily users',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Sam Smith, reputation AI at Consensys\nJosh Cassidy\nMichael Cena\nSarah Baker Mills (designer)',
        'What are the best educational resources?': 'Cryptozombies - the more modules the better\nChainshot - like codecademy, checks with unit tests\nhttps://github.com/ConsenSysLabs/ethereum-developer-tools-list/pulls\nhttps://medium.com/covee-network/here-are-the-best-courses-and-resources-for-learning-solidity-ethereum-dapps-600e18287381\nhttps://medium.com/bcgdv-engineering/getting-started-with-ethereum-as-a-developer-af20d78c49f\nhttps://medium.com/@wslyvh/getting-started-with-ethereum-solidity-geth-part-2-d195144fe6c7\nCryptomechanics.info\nConsensysacademy for a full course\nhttps://t.co/aRO7B8z50h',
        'Are there any other questions we should be asking?': null
    },
    '42': {
        'Name': 'Clement Lesaege and Nico Wagner',
        'How do you handle smart contract verification and security?': 'Write our own functional tests - but don’t provide proper security against malicious actor (can’t simulate those kind of network conditions easily). This is where fuzzing would be really, really useful. Try to understand how contracts could be exploited in ways that the developers can’t directly specify in tests.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Working on dispute resolution through smart contracts\nArbitration - process to decide who is right/wrong. Looks more like an arbitration DAO - system of incentives.\nEnforcement\nDecision-making\nIncentivising people',
        'What are the tools/libraries/frameworks you use?': 'Smart contracts - Remix\nBeing able to copy address directly is really cool now.\nStopped using remix core because writing tests in truffle is actually quicker than clicking everywhere through the `remix IDE.\nSolidity - can’t do operations in bytes. Want to split bytecode into address and integer and there is no easy way to do that. Could write some assembly (difficult to understand) or some hacky workaround that uses a lot of gas.\nByte manipulation is really needed in Solidity.\nAdd a solidity linter to Remix (already exists in Atom at least, but would be nice for having a properly integrated environment).\nWe really need a light client to use a DApp on a smartphone.\nTruffle to run tests\nRelying on other random libraries sometimes breaks things. If you use a library for tests that is not being used by your contract. I.e. it is very difficult to customise tests in truffle and you have to know some (undocumented) tricks in order to get around some basic stuff.\nBetter testing is required, more extensible and adaptable. We don’t need over-engineer things, but a better debugger and a properly integrated environment is necessary.\nTruffle doesn’t work with latest solc - keeping all the tools in sync and up to date is a tough task and it delays and blocks developers from using the latest tools if they have not yet been supported across the ecosystem.\nNo warnings for deprecation!!\nFrontend - ethers.js to communicate due to instability of web3. React, redux and redux-saga. Architecture with an API that is used to share methods needed to use Kleros easily.\nEthers.js is not well-known and it would be better to standardise things and have a  common library for everyone to use.\nMain issue with web3 lies in callbacks. They don’t use promises because the 1.0 version does not support them well.',
        'What are your biggest frustrations?': 'We REALLY need a very good web3 tool that is actually stable - the errors returned through the json-rpc are impossible to decode and find info on. Making this library more performant is a key issue.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'A tool to analyse security of smart contracts better, especially complex smart contract suites. Very excited to see formal verification, whenever that comes out.\nFuzz testing is super important!!\nGreat to use truffle boxes, but all of them are unstable and not well maintained. Would be great to see more effort put in there.\nTrying to implement chain-view: a tool to share the workflow of the ethereum protocol with the clients. Mostly used to analyse transactions (i.e whether they are successfully included in a  block) Can be very useful for client-side devs and i.t.o providing end users with transparency.\nNot open source currently.',
        'Other domain specific questions?': 'Pre-interview review from Nico:\nIt would be great to have a language like python, C to build smart contract to avoid learning a new syntax even if the syntax solidity language is good like the viper project (https://github.com/ethereum/vyper). The developers lose time to learn it.\nTo have a js tool to communicate with the node it is very stable and useful. We have encountered many problems with the web3 library. The library https://github.com/ethereum/web3.js/ (0.14.0):\ndependencies installation sometimes broke\nuse callback (promise is much better)\ncallback to know if a tx is mined break sometimes\nSo we choose to use ethjs.js instead of this tool. Apparently this has been fixed recently in version 1.0. But I haven’t tested it yet.\nAn easy tool to make a hash with a salt. It’s very difficult (for me) to find a library/hash function with the same hash than ethereum even more when there is a salt (https://gist.github.com/f43d7807b69402060dd6e4c8db730afc.git)\nA boilerplate to build a dapp like http://truffleframework.com/boxes/. The last time I tested this tool it was very unstable, so we prefer to build our own boilerplate .https://github.com/kleros/dapper.  A very good tool like this can be very useful for the developers to easily build a dapp with all tools to communicate with the ethereum protocol.\nA tool to sync the front-end state with the ethereum state like drizzle http://truffleframework.com/docs/drizzle/getting-started\nI haven\'t tested this tool yet but I was told it was unstable.\nTruffle doesn’t support the last solidity compiler (0.4.22)',
        'What was the hardest part about learning to develop with Ethereum?': 'Building safe smart contracts takes a lot of experience and understanding of game theory, cryptography, complexity skills and an insight into the edge cases that can be used to exploit certain patterns and implementations.\nThere is no single point to learn about all these domains, so it can be really challenging to get exposure to all of the required fields, and eve to realise that these fields are important to writing good SCs.',
        'What are you most excited about in the short term?': 'Decentraland rocks!!\n0x\nTruebit\nProof of Stake in general will be very important going forward. In fact, everything that allows for scalability and lower tx fees with higher tps is absolutely critical.\nIPFS is interesting too - right now they are hosting some part of the website/DApp themselves and that constitutes a central point of failure, so easy-to-use and maintain decentralized storage would be really, really great.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Github and Reddit are the most useful.\nr/ethereum sometimes has posts with a lot of documentation and that is almost always a great place to start.\nTrawling through GH issues looking for the comment that leads you in the right direction.\nReadthedocs is also super useful - esp for Truffle and Solidity.\nCan be very fragmented - there are a lot of sources and some are out of date etc. Not necessarily too bad to have a lot of sources as Google can generally lead you to the right place.\nGitHub should be the hub for developer documentation particularly.\nWhen I can’t find a solution, just googling is always very helpful. Sounds cliched, but someone else has almost definitely had that problem before. This often leads to a gitter conversation and the dev channels there tend to be fairly responsible.',
        'Are there any other questions we should be asking?': null
    },
    '43': {
        'Name': 'Dan Tsui',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'LLC that does consulting and builds projects\nTheir first crypto client was Metamask.\nOther examples: build UI on top of the smart contracts; how to integrate with scaling solutions.\nWorking with state channels on wallet. Should be live on 1st or 2nd week of April\nFirst: “productionizing” their library for micro payments.\nGot into this space contributing to the EthereumJS ecosystem.\nWithin the team, I function as PM and do code reviews.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'There’s the inner crew of devs; then there’s other teams who are trying to build stuff, but who don’t have the same access. There’s also language barriers etc.\nWe don’t quite know the lay of the land: e.g. “should we integrate with Metamask or build our own things”?\nKnowledge of tooling and documentation –– very fragmented / scattered across ecosystem.\nHow to incorporate layer 2 solutions?\nPeople’s roadmaps are defined based on their analysis of tech at the time of their ICO, even though new stuff is becoming possible nearly every day. Staying up to date with this is challenging.\nWhen we were starting work on Ethereum stuff we needed to learn. In order to do that well, we needed to talk to different projects as this is ultimately the best way to learn and the Ethereum community can be very welcoming if you just find the right channels.\nBut how do people know what to use who aren’t in the community: e.g. Metamask vs Mist?\nDfinity asked them to go through all the Ethereum dev tools\nThey use truffle, ganache, Remix - all the usual stuff.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'GK Chan - jchan@kyokan.io\nMatt Slipper - mslipper@kyokan.io - wrote UI’s integrating with Metamask & leading Spankchain wallet project',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '44': {
        'Name': 'Jacky & Matthew',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Matthew:\nCofounder of Kyokan, CTO\nClient work\nPlasma and Plasma Chain.\nState channels work with Spankchain.\nInfrastructural work + Solidity.\nJacky:\nCofounder of Kyokan\nBuilding / integrating with Ethereum wallets\nSolidity',
        'What are the tools/libraries/frameworks you use?': 'Matthew:\nWorking on plasma and writing it in Go. Focussed on interoperability between Geth and smart contracts.\nMy development style:\nI really like Java. – enterprise-y tools make me productive.\nIDE could be really improved.\nI use IntelliJ’s Solidity plugin to edit Solidity.\n“Jump-to-def”; “jump-to-implementation”; syntax highlighting\nBig difference in productivity.\nE.g. when I’m writing Go code, I can jump to the Geth definition. This is amazing.\nI’m switching between Solidity / Go, or Solidity / Javascript\nSolidity Javascript bindings through Truffle are good.\nIntegrating libraries designed for cryptocurrencies with front-end apps is hard:\nBundle sizing: different behavior if you’re running in the browser or in the backend.\nE.g. if you compile a contract with truffle, you get a JSON file – which has the bytecode and all this stuff beyond the ABI.\nThis is heavy and unused.\nCrypto.js has unnecessary dependencies:\nEth.js includes an ASN.1 parser which parses digital certificates –– which isn’t needed for any crypto.js uses.\nGoogle Chrome places a size limit (3 MB) on service workers in Incognito mode.\nBundle sizing is important – need to take out dependencies.\nStandardize the interfaces for all these libraries.\nE.g. a standardize library to read BIP39 seed words – across different programming languages.\nIs there a Javascript API to boot a testnet, deploy contracts, and run tests against it?\nFor running application tests –\nI want integration tests that run against Truffle easily\nHaving the ability to do this via Javascript is important\nE.g. automate this: https://github.com/machinomy/machinomy/blob/master/run_integration_tests.sh\nPeople don’t know how to productionize a geth node:\nOn Ubuntu: you can ‘apt-get install geth’\nNow, how do you secure it, monitor it, etc?\nPeople say: “just use Infura” – but then you’re tied to Infura.\nSome ideas:\nDocker instances; Chef or Ansible scripts; that setup a Geth node which has a bunch of best practices around it.\nAs an example:\nYour RPC port shouldn’t be open to the external world, but should be accessible to the front-end.\nYou need a layer sitting between the geth node and the external world, and gives: 1) analytics, 2) authentication, and 3) audit logging.\nThe dashboard could configure geth on the fly.\nHow do you secure a geth node with an RPC port:\nNeed only certain keys to be allowed to interact with it\nJacky:\nIntegrating Metamask with Dapps\nBuilding a new wallet for Spank;\nIt’s a service worker\nThree threads running at once:\nRuns a bunch of background processes\nThe Wallet\nThe Dapp itself\nThe messaging between these three threads sucks.\nCross-window JSON RPC library.\nWallets are pushing the limits of what Chrome is capable of.\nThey’ve had to file two bugs with Chrome in the last month.\nRuns into the service worker size limit.\nMostly Javascript and Web3 work\nLot of code repetition in loading state and confirming transactions\nWeb3 is kinda hard to use – large ABIs\nBiggest problem has been around event management.\nKey management is not that complicated – Web3 has a good handle on it.\nThe Web 3 interaction with the wallet:\nWeb3 provider talks to the blockchain –\nSpank and Metamask – the provider is an instance of the ZeroClientProvider – written by the Metamask team\nThe ZeroClient makes all calls when there’s no key needed. When a key is needed, it calls into your codebase.\nBiggest problem is around the communication of gas costs.\nThe UX around this.\nUsers pick really high or low gas costs.\nThere are better ways to estimate gas.\nWould be nice: currency conversion utility tools.\nExisting tools are pretty buggy.\nETH has many different units.\nUnits conversion.\nMatthew:\nI write all my own methods – other than lowdash where I pull specific utils out.\nReact / Redux.\nNeed a way of shoving Web3 stuff into your Redux state.\nManaging the lock state of your wallet\nE.g. you need the lock-state of the
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Plasma: the future is close – will see this live in 3-6 months.\nGeneralized state channels: L4 and Spankchain.\nPlasma Cash:\nThe idea of a coin that you sign over to different parties – it’s kind of like a cheque.\nCan replace other entrenches business –\nCan attach it to a stablecoin.\nIn-browser Ethereum light-client: Mascara.\nWe’re in the internet before packet-switching.\nAfter that, everything is open and possible.\nCan integrate cryptocurrency with your everyday life.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '45': {
        'Name': 'ANDREY PETROV',
        'How do you handle smart contract verification and security?': 'Write a lot of tests myself. Get other people to read it. Keep it as simple as I humanly can.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'https://thousandetherhomepage.com/',
        'What are the tools/libraries/frameworks you use?': 'Truffle - not his favourite, but best thing out there right now\nVim for everything\nEtherscan a lot\nRemix IDE - trying this out sometimes, but also my own editor\nTruffle\nAlso my own runner, written in go.',
        'What are your biggest frustrations?': 'Dapps: web3js stuff sucks. In the doc, it’s in a weird halfway state where its deprecated but there’s nothing superseding it. Its pretty broken in many ways. At least 4 solutions that are about 80% done.\n(ethers.js, but it doesn’t speak well to metamask. Fixed now 11/05/2018)\nUX stuff?\nCryptoKitties situation - lot of people want a basic way to swap a transaction with one with higher fees. That’s kind of an ethereum specific thing.\nScaling?\nLightmode thing with Geth -  a lot of users use the lightmode. In terms of scaling user base, that’s relevant. Eventually most users use lightmode, and right now its broken. [Related update: https://vipnode.org/]\nSpinning up more nodes is useful!\n(Campaign to show selfies with your nodes, every office should have a node or many, etc.)\nAre you running into problems with any of the following:\nGas limit\nProbably a truffle problem: it returns a lot of errors related to the gas limit, but they are not actually errors. Error messages are probably just not great.\nBetter errors on the gas limit would be useful to address underlying problem.\nOff-chain computation\nBeen thinking about some game ideas, and a lot of them require off-chain computation.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'Things I want improved with truffle: it has a lot of moving pieces. Reliant on the nodejs ecosystem and all that. Would like to see a binary runner - want to be able to have a binary, give it some solidity, and it knows how to run it in a simulated environment. Really useful for deploying continuous integration and stuff.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'A lot of tooling that isn’t there. Ecosystem is “bursty”: there was a big burst of dev for web3, but then it stopped, it’s not done, and it’s not advancing. Truffle seems to be same thing. Why? Well people build the stuff they need, and then they stop building.\nOperational security of the thing. Easiest way to use it right now is to install metamask, which is not great. If you install ina browser with other extensions, its as secure as other extensions. Installing mist is not happening. Sure it says write down seed so it’s safe, but doesn’t explain full meaning or ramifications of that.\nDo better about default backup practices. There could be automatic backup processes.\nBiggest risk is loss, not theft',
        'What are you most excited about in the short term?': 'What dev tools on near horizon that would change things?\nWeb 3 stuff is almost there but not quite\nNeed to look more into the ZK stuff which is cool, but needs more researchers on it.\nTons of room improvement for wallets\nMobile dapps are in the VERY early stage. Mobile wallets that can run dapps are just reaching market.\nStatus\nEthers wallet has it\nMetamask for brave mobile\nCipher',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Max Veytsman',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '46': {
        'Name': 'Liam Horne',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Co-founder of L4 and Counterfactual.\nTwo main things:\nLeading the development of counterfactual: a generalised state channels framework and protocol. It’s a simple, intuitive framework for developing DApps using state channels - so we do a lot of work on Solidity code and general work around EVM interactions.\nCo-founders of ETHGlobal - so I spend a bunch of time talking to hackers and making sure that these events represent genuine progress and that people aren’t just stuck on bugs. The output to time ratio needs to be as high possible.',
        'What are the tools/libraries/frameworks you use?': 'Truffle suite.\nHighest level comment: nice for specific use cases, but our use case does not match this. It’s built for writing a bunch of contracts, deploying them and interacting.\nOur whole framework is based around off-chain interactions, for which Truffle is not well suited.\nThe whole Truffle networks thing is kind of annoying. If you want to ship a simple build that you put in your browser and run, it doesn’t work locally. You need to set up your own test environment.\nWould be great to have a tool that could put together a super minified version of your ganache DB so that we could test across the same data.\nWe did some of this, but it’s not well known and not the default across the ecosystem.\nUse ethers.js a lot\nABI encoder v2\nNot supported by truffle.\nGanache\nCan be very unreliable for a lot of important things.\nE.g. bug in ecrecover on bytes (even if signed correctly) it will not return the correct address, It is just not implemented correctly, so we had to port over to Parity.\nHowever, the parity dev client doesn’t throw errors on revert, it just logs them, and there is no option to change this.\nThe fact that the behaviours are different between these two things is concerning and frustrating.\nParity and Geth\nI don’t understand why there isn’t just one-click Ganache replacement. If I just went to parity.heroku.app with a big button to launch an instance, that’d be awesome. Seems like low hanging fruit that could really be quite easily worked on.\nGetting around all the configuration details is such a headache.\nI just want to launch testnets, and even do so locally in a way that actually works in practice.\nAnything to do with solidity at all really.\nLibraries and tools\nRemix\nPlaying with rust for its ability to write once, run everywhere.\nTonne of JS tools to quickly iterate\nTypescript  - state channels need to run in the client, you want to be able to have code client side to decide what to sign and whether it is safe, and this is easiest in typescript. Would be better in WASM, but it’s not there yet.',
        'What are your biggest frustrations?': 'Better UI testing. Would be awesome to have am MetaMask mock - wanna launch Chrome Canary, Safari, Moz and ganache will auto inject into the page some provider that could be used to test the full flow. We have also started work on this.\nWe need more to more people working on ethers.js!!\nIt is the best library out there, especially for quick operations, and we need like 5 more people at least working on it,\nWeb3 is too opinionated about exact use cases, whereas ethers is much more generic and simple and can have a lot of tools built on top of it.\nWe have been hesitant to develop non JS stuff, and haven’t yet because there is no ether.js equivalent. If there were an ethers equivalent in Rust that would be awesome.\nIn terms of solidity: ABI encode and decode (not written well yet, but will be super useful) are really game changing! It should be 0.3 or 0.4 or something!\nReally bad documentation, especially around nuances to do with memory or storage objects etc.\nWhen things happen in solidity, what you can do with it is not explained well.\nFor instance, one thing you can do is now use returndatasize to get the output bytes from some call you make. The minimum amount of code you need is a few lines of assembly.\nHowever, this is not well known or used.\nOur whole system is based on off-chain contract, and the rules in there need to be enforced by on-chain contracts. So I need to be able to interpret arbitrary function calls based on arbitrary logic/user input. This is very hard…\nWe do conditional payments, and these ensure that a bunch of things  are true, and then interpret the results of a bunch of functions and then take those outputs and pay people. All of these inputs, not contracts, and it gets complicated.\nThere is a specific error called unimplemented_error which comes up in a few cases. The only way to figure this out is to google it and there are 3 or 4 options to pick from, which seems sloppy.\nError messages could be much more specific about WHAT is unimplemented.\nWould be great to see also in the docs WHY certain things are not yet implemented.\nThere’s some subtleties around exactly how libraries work in solidity. Will send through more details when editing.\nWould be nice to have a debug mode for events, so that they will trigger regardless of whether or not there was an error so that we can use that as a console.og\nAlso, there should just be a console.log ;)\nIf you emit an event with a dynamic struct and pass it a dynamic struct, the whole thing doesn’t make it back in the logs: it only shows the top of the event. It certainly doesn’t show the whole thing.\nWhenever you hit gasLimits, you should be able to find out easily where it stopped and what line it is stopping at.\nBetter documentation on the assembly command sand specific example usage of them would be really good.\nBreakpoints with context - these are the variables and scope etc. I will sometimes play around with delegatecall and then I don’t even know which context I am in anymore and this can block me for extended periods of time.\nThere’s a bunch of sneaky tactics: like keyless signatures. There is a way to generate a sig for an exact and specific kind of tx from an account whose nonce is 0, because then the create opcode gives back a deterministic address.\nPlease can we document this!? There should be a person on stuff who just plays around with this stuff and then documents it.\nThis is very serious stuff, if there were a keyless-sig library, so many other things would also be available.\nBetter google results for Ethereum!\nMore literature on how Ethereum can be used to do the things people think other blockchains are better at.\nHighlight ethresear.ch and some post sthere, like one from Vitalik about businesses paying gas fees for their uses, which is EOS’ biggest argument.\nEven worse, explaining plasma, where it should be feasible to have no fees at all.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'WASM is likely most useful for us medium term.\nState channels are very light in terms of the actual contract code. But the off-chain contract code is a lot more complicated. It would be nice if all of the things we’re doing were easily runnable in the browser.\nWe have this concept of a module, which is some software that wraps a particular state channel application. We need code running in the client that determines whether or not it is safe to sign the next transaction, and where you store it, if you show it to the user at all etc.\nWe then have to implement a copy of what the contract does in JS and it would be way nicer if we just had a local environment to run some eWASM code because then we wouldn’t need to worry about the node at all. We wanna have it work in any random browser and WASm enables that.\nPlasma and state channels require stripped and straight forward teams to work on this stuff that can build out all the tools we need.\nTruebit is exciting.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': 'Ethers.js. Really, it is super simple to use.',
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'I just read the code, man. What is the latest commit by ChrisEth on solidity? That is the best source.\nOtherwise, Richard Moore knows everything. Literally.',
        'Are there any other questions we should be asking?': 'It would be interesting to have a meta bounty for the most valuable stack overflow answers and that person gets a 1ETH reward.\nIf that became a really legit place that people in the community took seriously, that would be really great and of high value.\nGetting a good mod on staff to manage this and then put it out!'
    },
    '47': {
        'Name': 'RICHARD MOORE',
        'How do you handle smart contract verification and security?': 'Extensive testing!\nUsing ethers.build etc. code audits are usually from Yuet.\nUsually just have someone else look it over.\nMore careful with blockchain-things esp once my money is in there.',
        'Other bounties?': null,
        'Who are you and what are you working on?': null,
        'What are the tools/libraries/frameworks you use?': 'I use all my own stuff, mainly\nEthers.js\nethers.cli\nEthers.build\nParity\nNode.js',
        'What are your biggest frustrations?': 'Documentation is a huge problem\nA lot of documentation is simply missing, or its not good\nIt’s all outdated! It seems authoritative, but then I find it’s wrong. People don’t always do a good job of this. Ethers is only non-solidity implementation of solidity’s S3 that works correctly.\nIf you read the docs, it’s just wrong!!',
        'How do you handle testing?': 'Automated testing? How do the facilitate manual testing?\nEthers.build\nAutomated\nAlso facilitates manual testing\nRudimentary debugging',
        'What tools don’t exist at the moment?': 'Events!!\nThere’s definitely missing features of what ethereum actually stores in its DB.\nI would love if infura enabled the trace API, which is hugely expensive, that’s probably why they haven’t, but for now there is no way to give it an address and find all the transaction (or even a transaction) from that address.\nWould be great if you could just tell me the first tx hash that a given address ever made. Obviously this vastly increases cost of an ethereum node to run, but would be useful.\nEvents are just wildly unreliable. This is why ENS stores things on chain. Events don’t work well enough to do what you need to do. If I need to look this up, I can’t.\nThe main reason is if you indexed all that stuff all the time, it would constitute a huge load. So most people aren’t doing that. Scarce details of how they aren’t is the problem...\n[Greg is working on something that will do this]',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Install and setup and configure and run and sync your own chain is ridiculous.\nLibraries like web3 which have big problems.\nWeb3 feels weird given how javascript is used and behaves.\nWhat would be the hardest part of teaching somebody to build a dapp?\nMainly just the idea of how blockchains work. People tend to misunderstand what the blockchain part can and should do.\nIt’s very easy for a person to write a terrible contract. Even if you write a terrible MVP, it’s easy to release the non-terrible version later. But with this, if you make a bad mistake, it’s a huge problem - more like hardware, you can’t always change it on the fly.\nAnd the documentation sucks.',
        'What are you most excited about in the short term?': '0x is cool. Rufflet is neat! I like the idea of having introspection tools in the system.\nAlso: https://www.withpragma.com/logging/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d\nDebuggers are super important and I want them! Martin Swende demoed one, but needs some other stuff… his thing focuses on monitoring the EVM code and state changes its performing, as opposed to solidity. I want to be able to step through my solidity code line by line and see the changes that it is making on the blockchain.\nThe sourcemap is not super reliable. Because once you compile, it might reorder operations, and certain ops span lines, it starts becoming non-obvious what the correct thing to point to is.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Yuet Loo',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '48': {
        'Name': 'James Childs-Maidment',
        'How do you handle smart contract verification and security?': 'No process, but would love to have it.\nApart from testing, would be cool to have tools that analyze what you’ve written and make sure you’re not doing anything dumb.\nRight now, using Remix is helpful for getting warnings and stuff.\nHasn’t used Oyente',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Been building social apps on Ethereum. Leeroy.\nStoring all posts and likes on-chain, syncing that with a centralized database and frontend.\nI started with some little smart contract that saved a string to variable.\nAfter that, just dove in on making Leroy over the next few months.\nAfter getting a feel for solidity by playing with Remix.\nDidn’t really understand how expensive it would be to save everything on the blockchain. Solution was to store the hash of all the inputs.\nFrom there, had to learn how to make things as cheap as possible.\nQuite a bit of smart contract work on Leroy. Multiple versions of the contract along the way.\nBecause it’s as cheap as possible, Leroy doesn’t even fire events.',
        'What are the tools/libraries/frameworks you use?': 'React / Redux app, with a firebase backend\nTruffle. Just deployed using Remix, and uses it for playing with the contracts in general.\nIf not already mentioned, are there any libraries you rely on regularly?\nWeb3JS\nIn a toy project, used MetaMask just for signing transactions. Had a separate web3 using Infura for other stuff.',
        'What are your biggest frustrations?': 'The tools are pretty early. Constantly running into a ton of bugs.\nOn Leeroy, had to install packages and fix stuff from other projects that were broken so he could use them.\nYesterday was playing around with a new app, and was using Ganache, and it would just lock up and crash. Then you need to redeploy the local smart contracts, which takes about a minute to get up and running again.\nA really stable local chain would be cool.\nWith solidity, it would be great if you could get a better view of what went wrong when a transaction fails.',
        'How do you handle testing?': 'Truffle for testing (JS unit tests).\nReally enjoying writing async await tests with Truffle.\nAutomated testing? How do you facilitate manual testing?\nPlay with the contracts in Remix. Deploy the contracts to testrpc and then test manually using the UI.',
        'What tools don’t exist at the moment?': 'When you use Web3 library with Metamask, it’s really crappy getting events coming through.\nMaybe will get fixed when moving to websockets with 1.0',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Only started in June or so.\nJust reading through github and reddit instead of an actual source for education. Having really good docs in one place is a big thing.',
        'What are you most excited about in the short term?': 'Aragon.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '49': {
        'Name': 'Yondon Fu',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Previously: working on smart contracts.\nTruffle, testrpc / ganache-cli.\nExpanded our test suite so they could run on multiple clients: could point at testrpc, at geth or Parity on PoA mode.\nNow: Golang for our node.\nIntegrating our smart contracts with their node that does video-processing.\nWorking with Geth. There’s packages for interacting with EVM.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Livepeer that runs as Daemon, unlock your wallet, give this an in-memory key. They have a DPoS protocol built-in.\nSimilar operational problems as someone running a validator node for Casper FFG\nHow does Daemon have access to private key, in non-manual confirmation from you? How do you do this securely?\nWhat’s the proper key management flow. Not necessarily a bounty, but shared knowledge.\nNeed better documentation\nSome of the new things you need to use are not documented yet. Writing documentation is a good way to introduce someone to internals of a project (they need to understand stuff to write the docs).\nExample: heard this from Eric at Livepeer, there’s a tool in Geth called Pupeth: uses Docker containers to set up an Ethereum private network, gives you dashboard - would be awesome.\nlibp2p (networking layer for IPFS) especially since it’s gaining a lot of adoption but the examples for getting started are still a little sparse',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Smart contracts:\nContract compilation time is slow. We use Truffle compilation, which I thinks uses Javascript-bindings for C++ compiler.\nSometimes the compilation takes longer than the tests.\nRunning C++ compiler (solc) without the Javascript binding is way faster.\nCan Truffle use the Solidity compiler internally, without the JS binding?\nMaybe this is an easy feature add[a].\nI’ve played with DappHub. It’s much faster.\nIt would also be helpful to specify a compiler version to use without using a completely different version of Truffle\nIf you make a change, Truffle tries to be smart about which contracts to recompile. Sometimes this doesn’t work and you need to blow away /build dir and recompile. Not a great UX.\nIn ‘truffle console’: using JS promises are annoying –– can be verbose and hard to read.\nWould be cool: having a transformation of that console, if it had async/await, or some kind of wrapper to make things seem synchronous.\nIf I see an error in a contract:\nDebugging sucks. Right now: comment out code, recompile, deploy, run again.\nSolidity is adding a “reason” string for the revert message. So you can have reasoning!\nThey have an internal Ethereum testnet running.\nWriting the Go client:\nPain point: nonce management –\nOptions:\nGeth web3.sendTransaction: geth sets the nonce for you.\nThe other option is to pick the nonce yourself.\nFor our client, we do the nonce management ourselves: there’s a method to get the Nonce, and includes transactions in “pending” state, but you don’t know them if you’re not a miner.\nThis is an issue if you submit concurrent transactions.\nParity has a custom method called nextNonce, which works properly –\nParity vs. Geth different methods – there’s more room for cross-client feature sharing, adding things into the standard RPC interface.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Guys at Aragon – Jorge or Oliver.\nEthereum Natural Specification style – basically a commenting style that can have auto-generated comments from it. Aragon is building a custom version of this.\nZeppelin.\n0x\nBeen putting out good developer tooling. Really into Typescript, static typing.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Have we considered Grants, for longer-term things, vs. simply bounties?\nE.g. Debugger would require longer-term maintenance, needs to develop in pace with Ethereum development. One-time bounty might not be enough.\nMight be a fit for longer-term projects. Milestone-based?\nNicola Greco had some interesting ideas about incentivizing more open, collaborative academic research - are there learnings from thinking in this design space that can be applied to general open source?'
    },
    '50': {
        'Name': 'Eric',
        'How do you handle smart contract verification and security?': 'Internal security audits. Taking time to do thorough code reviews.\nTrail of Bits did a security audit\nLaunch has been great, it’s been a month and they’ve learned a ton. Bigger and bigger community call, can test economic assumptions on the Mainnet.',
        'Other bounties?': 'Identity solution. ENS exists but like a great solution that’s built on top of ENS doesn’t exist yet. Some solution around there is interesting\nReputation system on addresses. Addresses are participating in all these protocols. The network effect you have, the behavior of the one address in one protocol can predict in others. TrustDavis is an interesting paper on this.\nTruebit is something that a lot of projects hope will exist. They are collaborating with them closely. They already have a prototype that’s working and are excited about this',
        'Who are you and what are you working on?': 'Been working on Livepeer for 2 years, before this was an entrepreneur. Was interested in Bitcoin in 2015 and saw Ethereum launch in the same summer as Steemit. Those two things got my attention.\nOne of the things we found in web2 is that video facilitates transactions. Companies make a lot of money by charging a big premium for this transaction. 30-80%.\nStarted to get more familiar with decentralization, wanted to build a video protocol that is cryptonative. Crypto payment by the packet. No payment channel so needed a decentralized video infrastructure.',
        'What are the tools/libraries/frameworks you use?': 'Use web3js a lot, we use a lot of peer-to-peer networking in addition. First version of livepeer was a fork of Geth codebase and adding video streaming, since then we have a brand new code base.\nDelegated proof-of-stake system for electing service providers in the network. All built in Solidity, use Truffle for this.\nUse some Trail of Bits for security stuff\nUse IPFS for storage\nTruebit for decentralized computation verification\nCollaborate with Swarm team for video distributions\nThe way our tech works is we depend on Ethereum for protocol but our own peer2peer network for delivering video. We create our own network while every node talks to Ethereum, can get complicated.',
        'What are your biggest frustrations?': 'When we first started was still pretty hard to write code in Solidity, Truffle was just launched. That was a big hurdle. We operate our own Ethereum test network which has its headaches.\nThere are quirks in the Ethereum network that are not documented.\nThe Ethereum network in general does not do event subscription, notifications don’t work great here. Most popular tool is in Infura but their websockets are pretty flaky\nWe ask people to run Geth lightnodes, these have less overhead than full nodes but are still a bit of overhead.\nWe found a bug in the code and then did a smart contract upgrade process  using a proxy contract pattern which saved us. Upgradeability doesn’t work super well. Doing the upgrade, communicating with the community, etc. was a big undertaking.',
        'How do you handle testing?': 'Do a lot of unit testing. Try to cover as many cases as possible to make sure the code quality is high. There is not a lot of guarantee in terms of testing for security.',
        'What tools don’t exist at the moment?': 'Better Debugger comes to mind. Monitoring systems and alerting systems. Metrics gathering systems. No one has figured a great solution for this.\nWhere do all the data live? Can use IPFS but you have run IPFS yourself and the solution doesn’t perform well. One big research question is data availability problem. A lot of protocols work because they depend on punishment for bad behavior. But to prove the punishment requires data. For Casper that’s fine, but or other protocols that doesn’t work. If you rely on off-chain data can make this data unavailable for an attack vector.\nTransaction Attestation Platform (TAP). Different interfaces on a smart contract. How can people trust that the smart contract underneath is the thing that they’re thinking about. Kind of anti-phishing. Give a reputation to a smart contract. Show this to a user in a standardized way. It is a decentralized platform that users can use to attest to the trustworthiness of smart contract functions that other users will have to invoke in order to interact with DApps. http://dappbench.com',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'The amount of technologies you have to be familiar with is much larger than other tech stacks. Security, new programming language, JavaScript to interact with the contracts, game theory, sheer amount of knowledge that you need to get started is quite high.',
        'What are you most excited about in the short term?': 'Really excited about Casper, gonna be cool to see. Proof of stake at scale. How it affects the economics in the ecosystem.\nSome layer 2 solutions that become fully usable. Past theoretics. For POA Network, the explorer is currently not there.\nPlasma is longer term. Cosmos is coming online, Ethermint afterwards. Loom network, etc.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'SuperMax Project, protocol explorer for protocols that are living on top of Ethereum. Build for Aragon, CryptoKitties, etc.\nConnecting dApp developers to protocol developers. A lot of projects building on top of Ethereum that he knows need both. As of yet unnamed project but will connect.',
        'What are the best educational resources?': 'Tutorials on Ethereum home page. He always tell people to start working on a pet project and that’s the best way to learn. Instead of going through a tutorial you should think about something cool and that’s simple enough that you can build your own thing.',
        'Are there any other questions we should be asking?': null
    },
    '51': {
        'Name': 'James Duffy',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Some type of tool that would take ETH Smart contracts, pack them up and automatically deploy them to mainnet.\nHeroku style CLI deployment tool or in-browser version.\nMaking deployment easier for testing and production.\nSolidity is really “bare bones”\nHard to manipulate strings -- not present in Solidity\nWhen trying to give examples in CryptoZombies -- couldn’t do much\nComparing strings -- no substring function\nWould be nice to have more “Utils”\nStarted Solidity X\nSuperset of Solidity that compiles to Solidity (intelligent defaults and prevents security issues)\nThink coffee-script for Solidity -- plan to continue development in the future',
        'Who are you and what are you working on?': 'Hybrid online marketing + developer\nInvested in Bitcoin since 2013, huge fan of the philosophy of crypto. I forgot about it during the 3-year bear market, then interest resurged in 2017 when I discovered Ethereum\nMy co-founder Luke was working as lead developer at crypto company called Block Mason\nI wanted to build new project because I was running into scalability issues on Ethereum. Matt was running into same issues -- things were too expensive and some really bad UI in general.\nThe project evolved a lot: the initial idea was called ETHDeploy. We were giving people a way to spin up EVM-based side chains on private test networks for demo’ing and user trials.\nDigital Ocean style way to spin up ETH-based blockchains.\nTo get adoption, we needed to build up our own applications. When we started doing that, we realized it didn’t make sense to build EVM stuff in Solidity and built in Go.\nNeed developers building on platform - so built CryptoZombies\nFirst, we built ETHFiddle which is Fiddle for Solidity -- like JSFiddle (inbrowser IDE for Ethereum to share code. Like Remix, but you can quickly share code snippets.)',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Deployment is “tough” - initial problem we set out to solve\nWhen first building DAPP, testnets are a mess:\nJust don’t work at all - people eating up all the transaction bandwidth or DDOS them.\nFaucet to get ETH on testnet is hard to find and use at scale.\nSetup local development with Truffle / Ganache, which is fine, but once you want to get it live to demo or do anything really useful, it is quite a headache.\nOur CTO just deployed it to testnet, which was less of a headache. However, deployment to mainent itself is quite difficult\nETHDeploy: auto populate wallet with huge amount of Ether; test things without having multiple steps; blockchain clone.\nBecame less of a focus for us. Doing something with Loom had potentially a much bigger audience and more use cases.\nStill need transaction costs on main-net down!\nOur argument is that not everything involves high storage of value / sensitive data (doesn’t need full decentralization), but we still want important parts on main-net (character data, owning items)\nDelegate Call (first app): users earn karma and tokenized karma they can transfer to mainnet for contributing to site.\nCould load cryptokitty into platform (ERC-20 + ERC721)\nStoring hashes of large amount of data verifiable on side chain. Mostly using relay to transfer tokenized assets\nLimited experience on mobile, which limits user adoption. Steep learning curve there\nMetamask is most straightforward thing, but not sure how to improve.',
        'How do you handle testing?': 'Truffle / Ganache. When it’s time to test on a real network, sometimes just deployed to mainnet .\nIn-House guy out of NYC that does contract audits\nOpen Zeppelin stuff is awesome\nUse own ETHFiddle to hack on code in the browser and share things with other people\nCompiler output not good: just does a diff check.\nTried embedding Solidity Compiler, but errors weren’t descriptive enough',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Loom - tell us more about games on the blockchain\nLots of people working on games and some early successes inspired lots of people.\nGames will be first real use case outside of financial payments\nIn-game assets that you physically own and can trade; real digital scarcity and users running nodes with the power of forking (nodes can reject changes to games) means an entirely new frontier of possibilities. Developers can’t shut down the game!\nShared game worlds because data is open on blockchain\nThink it’s going to be easy to gain user adoption with in-house game studio and building three games.\nLoom is developing an SDK to the point where it can be packaged and used by public\nGames and social apps -- anything could run on these sidechains\nNeed constant feedback of teams trying to use it, so we can iteratively improve it\nPluggable consensus mechanism.\nDPOS that we built in-house (like Steemit type) social sites\nWe plan to support Casper / Tendermint. Not usable version that’s public, the byzantine fault tolerant mechanism specifically.\nCore developers are close 20. Cofounder has done projects at Bloomberg, Digital Ocean, spoke at 20 Go conferences over past couple of years. Friend out of India runs team of senior developers, have had a team there from the get-go.\nNot being based in US means cost is much lower\nA lot of: senior back-end developers that had worked with distributed systems\n1 SDK building in-house; games to demonstrate platform, onboarding game companies (Unity)\nMake it easy for normal devs to make the jump into building blockchain dapps!\nCore developers at Loom are close 20. Cofounder has done projects at Bloomberg, Digital Ocean, spoke at 20 Go conferences over past couple of years. Friend out of India runs team of senior developers, have had a team there from the get-go.\nNot being based in US means cost is much lower\nA lot of: senior back-end developers that had worked with distributed systems\n1 SDK building in-house; games to demonstrate platform, onboarding game companies (Unity)\nMake it easy for normal devs to make the jump into building blockchain dapps!',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '52': {
        'Name': 'Matthew Di Ferrante‏',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Audits\nSome clients have their own testnets. Or some chain state that needs to be initialized before you can run the code.\nSmart contract dev –\nDecentralized exchange project –\nTesting that is hard. You need to deploy on chain; there’s a vault, ownership, hierarchy. How does the moving average work? You gotta run a 1000 trades and they have to be from the same account, etc etc\nI wish these tools had a dev mode – where you can deterministically generate accounts\nGeth & Truffle & etc should have a 1000 accounts that always show up as the first 1000 accounts.\nE.g. for testing signatures.\nThere should be a templated test environment; that you can use across environments, installations, etc.\nI find himself editing this a lot.\nPeople often give me tests which have addresses hard-coded in. I then  have to set it up again.\nConsistency:\nGetting projects to sync up; or a tool to initialize the setup for different projects.\nCan use ganache or testrpc upto a certain point, but then, it doesn’t scale.\nSomething that takes one second to run in geth, takes 20-30s on ganache.\nA tool that seeds the addresses, accounts – environment imaging.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'How long does it take to setup dev environment & tests.\nOn my own computer: I don’t use ‘npm install global’ or ‘npm’ at all –– I’ve created my own vagrant script, which specifies where I install stuff.\nIt takes a long time – 1, 2 hours – to update part of the environment.\nIt’s a huge barrier to entry\nAlso, a huge barrier to experimentation.\nMaking something where you can from idea to execution, would be great.\nRemix doesn’t work for complex interactions, or with something that’s already onchain.\nThings get truncated in Javascript.\nI wrote my own Python stuff – for handling bignum calculations and submitting to the contract.\nWe need better support for interaction with contracts that have non-trivial inputs:\nE.g. if you need to some pre-processing.\nCommon patterns across projects I’m auditing:\nThere’s limitations to the Solidity compiler – simple fixes could help the rest of the ecosystem make less mistakes:\nE.g. imports:\nIf you import an interface, then you have to link to a contract onchain. Or you can directly import a contract.\nHaving a pre-approved list of contracts –– there’s no reason to be redeploying things on the chain.\nEthpm does this – but worth adding support for this in the compiler itself?\nPeople roll their own complex math:\nBecause Solidity doesn’t have floating point, people come up with binomial approximations etc.\nTalk through a complex audit and how the process works:\nFirst: site-read the code.\nNotice small details: e.g. there’s an unbounded loop here.\nSetup the environment\nActually execute the code.\nStep through the code with a debugger:\nI use EVMLab – shows opcode per line with the state.\nNotes:\nI have a lot of hack-ish tools I’ve built himself. Would be nice to standardize these.\nFor audits: I don’t look at the offchain stuff.\nHow do I get testnet eth?\nOn Ropsten: I have a server.\nSome clients have their own testnets; I forward through their machines\nIf I need a lot of testnet eth (eg. testing a reverse dutch auction): I might spin up my own dev net.\nMoar?\nHaving a setup tool, like truffle init, which initializes keystore and an initial chain state where each of those addresses have a balance\nYou’d run this after ‘npm install’, ‘truffle init’ in your workflow\nGoing from ‘truffle init’ to a working ethereum setup takes too long',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '53': {
        'Name': 'Jenna Zenk, Travis Jacobs',
        'How do you handle smart contract verification and security?': 'Continuous integration with tests and Oyente integration\nUse Oyente.js - Melonport has sponsored the development of. Knows certain set of issues that have occured in smart contracts.\nRegular code audits (4). Before they go live next February, planning for 2 more audits. Audit from Nick Johnson and Martin Swende. Audit from Deja Vu. Last audit from bug bounty- Nick Munroz from Solidify. Also running a main net bug bounty.\nThinking about formal verification but costs associated with it is really high.',
        'Other bounties?': 'Javascript library and\nLight client',
        'Who are you and what are you working on?': 'Decentralized asset management system. Smart contract that allows you to set up and manage digital assets.\nFeature complete protocol going up to mainnet for short period of time for testing.',
        'What are the tools/libraries/frameworks you use?': 'Smart contract: Dapp by Dapphub. We manage packages with git modules. Includes Solidity compiler.\nSubpackages delivered as git submodules i.e. safemath.\nUsed truffle in the past. When you make a large project of truffle it becomes too complex. Not a fan of the migrations script. Record migrations on blockchain with an actual contract. Can’t run specific migration scripts, must run sequence of them. Need to recompile every time you do migrations even if contract code hasn’t changed.\nParity.js used for testing and deployment. Doesn’t have much error handling beyond what we’ve requested. Uses parity specific JSON RPC calls- can’t deploy to Geth or Ganache nodes. Looking to switch.\nDidn’t use metamask because idea was to have mobile compatibility- therefore didn’t see the value of metamask and were less feature complete. Internally developed in-browser wallet with Ethers.js works on all devices\nEthers.js library- really great. Only used in front end stack. Great because it’s not dependent on Metamask. More tools needed like Ethers.js that are maintained well.',
        'What are your biggest frustrations?': 'Coverage tool with truffle worked okay, but nothing available for DApp.\nSolidity’s lack of error handling.\nWeb3.js is far from mature, Eth.js looks okay but not to many people using it. Ethers.js is good for wallet management but a bit monolithic. JS library that will emerge as a standard is the one that maintains it. More functional JS approach from someone who loves Javascript. Event watching, querying blocks.',
        'How do you handle testing?': 'Use Parity.js for deployment on test network\nFor testing- use Ava javascript framework',
        'What tools don’t exist at the moment?': 'Really good .js library, better standard. Our front-end would love to help with ideation/funding.\nWe almost have to ask users to run full parity node to not affect our Node, force downtime. More community-available Nodes or otherwise light clients. Infura is completely owned and limitations such as querying limits and looking far back into history.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Light clients\nGraph protocol - create a data layer that caches the blockchain that sits between in SQl database.\nIPFS, OrbitDB.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Stack Overflow is best for practical development issues',
        'Are there any other questions we should be asking?': null
    },
    '54': {
        'Name': 'Aaron Kumavis',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'We’ve had good experience with bounties – Gitcoin,\nOne issue: bounties denominated in ETH or tokens, which leaves them open to volatility and potentially unhappy contributors.\nGitcoin, has ERC20 support, so you can use DAI now, which should help significantly.\nPeople sometimes do crappy jobs, then get angry that they’re bounty wasn’t accepted. This is, in a general, a problem between intrinsic and extrinsic motivation which still needs to be solved.\nInternally requirements change sometimes, leading us to not wanting to accept the solution even it abides by the initial spec, because we’d need to do a refactor around it.',
        'Who are you and what are you working on?': 'Whymarrh: contracting in the space, working on Metamask UI, working at Kyokan.\nKumavis: co-founder of MetaMask.\nwallet functionality;\nnot losing your private keys;\nshowing you what you’re signing, and what the side-effects of that are;\nchoosing a good gas price\nUsing Ethereum.js, Eth.js.\nOne thing we don’t do well – conveying on-chain errors that happen during tx execution.\nWant to be able to go deeper.\nSource map tooling. Here’s where it exactly went wrong.\nWant: an API to get source maps for published contracts.\nSource mapping tool already exists.\nGive it the trace information. They can generate this themselves using the json rpc.\nFind where it reverted.\nThrow that into the source maps.\nThat’ll give you the original line it was on.\nCould do more fancy analysis: find what values in the state are.\nNot sure how useful this would be the average user.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Usability\nChallenging because there’s a large range of users.\nE.g. Kenny at MakerDao who’s now at RChain. Hiss job was to manage the multisig for their funds. He’s sent a 1000 transactions on Metamask, he’s always signing, approving, etc.\nE.g. other people have no idea what’s going on, want to participate in an ICO. Any extra information you give them confuses them.\nToyed around with the idea of presenting two different ideas. Advanced mode.\nWe have a whole support team.\nSome tickets are sophisticated bug reports. Some are “hey, you stole my money”.\nWe’re trying to build general education resources.\nBounty: Ethereum for dummies.\nIn Metamask support –\nWhat is a private key, what is a seed phrase (most important!)\nTokens are initially straightforward. But looking at a block explorer, it says my tx was sent somewhere else.\nWhy do I need to pay ETH to send a token to someone?\nGas prices.\nMetamask can share learnings from their support team.\nWhymarrh is introduced in contributing few hours.\nThinks videos or walk-through could be the best medium for explaining complex things.\nKauri can have specific documentation for technical stuff.\nTransaction confirmations\nWe need to explain what is happening to our users. The DApp could be lying about what’s happening, which makes it extra complicated/interesting.\nMetamask receives a tx from the DApp, but no more info.\nHow do you convert that into a message to the user?\n“It looks like its talking to a token contract; or sending a random blob of data...”\nTake that low-level data and have to convey to the user what’s happening.\nWe have special cases – e.g. a token transfer, this is an ERC721, this is a DAO proposal, etc.\nThere’s non-normal stuff – e.g. what’s it like for a sidechain?\nMulti-network –– how would it work for non-Ethereum stuff?\nE.g. secure scuttlebutt.\nE.g. Filecoin, Dfinity, etc.\nE.g. Plasma chains inside of Ethereum.\nStandardization of transactions, blocks, signatures, etc.  –– not bounty-able right now. Need to build an architecture around it.\nThen, you need plugins, which could be a good fit bounties.\nScaling. We have 1m users...\nA lot of the work for scaling has happened inside of Infura.\nPart of it is just throwing money on the fire.\nThey developed a REST api for json rpc. So now they can put a CDN in front of it, and get caching.\nBut now, a standard provider can’t point at the REST interface.\nSeems like the big need is for standardization.\nE.g. Maker’s ERC20 version doesn’t match the standard.\nThat’s not because we don’t have enough conversation, it’s that we don’t have real governance.\nInfura is an existential risk for Metamask, because it’s expensive and we’re a non-profit.\nWe’ve been working for a while on their light-client. We’re blocked by some libp2p internals.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '55': {
        'Name': 'Dan Finlay',
        'How do you handle smart contract verification and security?': 'Regularly TDD. Write a lot of tests. Truffle, dapphub etc.\neth-js or web3 to deploy contracts and write tests over to that.\nLow-level js test. Thin wrapper around json-rpc, compile with solc, deploy straight to rpc. Used truffle v1 and they changed api, so truffle was behind. Switched to remix.\nOn metamask we use tests and QA. Automated tests and user tests.\nUnderstanding the blockchain in the first place.\nWhat’s happening under the hood and why I would care.\nA big challenge people hit the first time is reading from blockchain versus proposing a change.',
        'Other bounties?': 'https://ethereum-magicians.org/t/strange-loop-an-ethereum-governance-framework-proposal/268/24\nThere’s a road map that needs to be executed for this to work. If I had to guess, here’s how it might unfold:\nA client team with incentive to encourage a hard fork might implement “accepting on-chain hard fork proposals with client parameters” as a way to make it easier to develop the hard fork, in a community-focused way that gives users the power of choosing future forks in general, not merely supporting their own interests.\nOnce one client has implemented this, they should advertise their client as the client that gives the user the most control over the fork policy that their client uses, in hopes to either steal users to that client, or pressure other client developers to relinquish their own privileged decision making position by implementing support for the same.\nThere will probably be a friction period, either where some client devs don’t want to support this feature (either out of conviction or seeing it as a waste of time, since they may not want or need any hard forks), and so it might come down to people who have the most at stake (for example, people hoping for a funds recovery) to fund the development of this general feature for all clients.\nIf core client developers aren’t interested in supporting user-chosen hard fork policies, and refuse to review/merge these PRs, that might be a good reason to fork those clients, with hopes to merge after the changed version is proven stable.\nIMO, any client not favorable to a user configured fork choice rule is entrenching their own power, and informed users should flock away from those clients as other alternatives emerge.',
        'Who are you and what are you working on?': 'User interface platform apps - Apps that enable other apps.\nA few gateway apps.\nFirst layer of education making it easier for users to interact with other apps.\nI started with the original “Hello, World” Greeter contract from ethereum.org.\nI liked it so much I forked it.\nOriginally they had 3 tutorials: Greeter, Voting, and Crowd-funding - would be great to see that kept more up-to-date...',
        'What are the tools/libraries/frameworks you use?': 'React, gulp, javascript, browserify.\nMocha for testing, build live reloading.\nweb3 api and rpc api.\nsinon mocks.\nCreate a UI for smart contracts, run testrpc, deploy contracts, and query it.\nIf not already mentioned, are there any libraries you rely on regularly?\nweb3, eth-js, provider engine deprecating for json rpc engine, react.\nbip-39, web crypto libraries.\nCurrently developing eth-keyring-controller',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Test network, mainchain, local test rpc, mocked user interface.',
        'What tools don’t exist at the moment?': 'The ability to make really lightweight user interfaces that subscribe to blockchain state.\nWould prefer that json-rpc return promises.\njson-rpc is unperformant, wish it was easier to contribute to.',
        'Other domain specific questions?': 'EIP-719 would make a great bounty to make this. Contracts exposing a way to request a human readable. render approval screen.\nCould make transaction process human readable.\nMoonlay by Mist team[a] is interesting and deserves more attention.\nBrowser permissions. These require browser vendor cooperation. The only way to expose web3 is to require read/write access to all websites. But we actually only want to expose to a few participating websites.\nWeb3 api',
        'What was the hardest part about learning to develop with Ethereum?': 'Ultimately these things are not usable yet, because blockchain isn\'t scalable, and blockchain hasn\'t scaled. This is not a pleasant way to build applications.\nAlso, a lot of patterns aren\'t defined yet.\nFor example, in CryptoKitties when you lock a kitty, another user might retry kitty.\nIn general, conveying to the user [who is interacting with a smart contract] what\'s happening under the hood is frustrating.\nThere is a big chasm between what people are used to with current application and blockchain applications, i.e. things like gas.\nCryptokitties is great example of what developers are capable of creating on the blockchain. Established web design firm. What decisions did they make based on docs?\nWe need to address what constitutes a production grade app.\nScaling is eventually a part of that. Plasma chain interaction might look like in a web app.',
        'What are you most excited about in the short term?': 'Looking forward to helping people access funding for opportunity they didn\'t have before.\nNon-profit to voluntary social infrastructure, small businesses that would have.\nSocial token launches. Make it more accessible to launch and sell coins for small businesses.\nWeTrust, Bancor, Circles, Curve token issuance, Puddle, Ripple’s trust lines which is getting adopted by Raiden, Open Baazar Trusted, Keyva, Geo, Sherpal, Building Societies.\nAlso excited about remote keys stored as a service, i.e. some service to store consumer keys.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '56': {
        'Name': 'Christopher Brown',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Full stack web dev, working in finance and some other industries. Started in Eth after reading WSJ after Frontiers release.\nVM was interesting - run code in the blockchain is really interesting.\nModular.network - working on a hybrid solution with Blossom.\nSeveral microservices in AWS that are coordinating with SCs on the blockchains - all that talk to a frontend dashboard\nToken contracts\nMore extensive libraries now - we have an open source repository for ETH contracts.\nMath\nToken\nCrowdsale\nArray handlers\nLinked lists handlers\nLanded on Status repos first when looking at this stuff :)\nLooking at zeppelin’s libraries and they didn’t seem as organised as other strong OSS libraries.\nAll about documentation!! Seemed lacking and this is the focus at modular.network.\nNot deployed libraries you can link to.\nModular deploys on all networks and you can link to them specifically using delegatecall.\nTake ERC20 - no reason to have 10000 Full implementations out there, just need contracts to hold their own storage and implement the right interface.\nBridging tech is most important for foreseeable future due to efficiency concerns on chain.\nETHPM required for graceful handling of libraries and packages, easily, securely etc. Really need to focus on that.\nHave some thoughts about using on chain tests for upgradeability.',
        'What are the tools/libraries/frameworks you use?': 'Truffle for building, testing and compiling\nCan be sketchy on deployments, though this has improved recently. Built our own deployment script to get around it though.\nTest, compiling and running are cool, but none of them are linked very well.\nBeing the devs of both ganache and truffle -putting the scripts together that would run the whole suite would be awesome.\nNeeds easier integration with CI tools.\nTest scripts from zeppelin (in the sol libraries that pulls up testrpc, gives it a bunch of accounts and then executes whatever you have written).\nDive into lower level Ethereum libraries a lot - ethjs-utils especially.\nYou have to understand what is going on and WHY you’re doing it. This context is tough to get across and the libraries here are just not as well advertised, which is a pity.\nIt’s a maturity thing: early on you’re just trying to attract people and get them to get their hands dirty. As the community matures, you need more forward-facing, lower-level libraries that are well documented available is absolutely key. You can only do so much with vanilla web3..\nOne of their new implementations is a new multisig wallet, picking up some stuff from ERC 191, added some things to address security concerns.\nNone of that stuff is in web3, so using ecsign method from utils in order to avoid going onchain all the time to get info that is available elsewhere.\nMore attention around lower level components is useful as we mature.\nEthereumjs-tx, ethereumjs-wallet, solidity-sha3, to get identical hashes\nLittle bit more control to JS devs.\nWeb3 1 looks good\nBiggest mistake: made it default installer when web3 v1-beta came out and this is a crucial error!!\nBut scrypt is such a heavy package to deal with. We use that for local encryption/decryption now. Can it even be compiled into an Electron app for instance?\nNecessary because everyone running full nodes is never gonna happen.',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Just Truffle for tests\nMocha for unit and functional tests. Use mocha across the whole application base.\nHave run Mythril on some mission critical contracts\nWas a pretty good experience\nStay away from monolithic code bases, iterate and test as regularly as possible!\nApplies especially to smart contracts\nUse event logging to debug contracts if possible\nGetting invalid opcodes as feedback when your code doesn’t run is the single most frustrating thing in the world!\nThis has now improved a lot, which is awesome! Not just OOG errors in solidity anymore.\nFinished contracts a few months ago and now don’t really want to touch them too much. However, solc moves on a lot and there is a tension there (especially after audits)\nSC dev is much more like traditional application dev, not web dev. Updates are months apart and very purposeful, bundle a bunch of things etc.\nWe like solidity, and most problems are related to VM not being as capable as people currently want.\nThere’s a language called Jelly with very purposeful functions that are then linked together to create compound functions.\nSomeone wanted trailing and leading 0’s from contracts return data - seemed very easy to do in Jelly. Specifically, bytes are so valuable on the blockchain and we use more bytes than we need to.\nRoom for optimisation with bytecode there.',
        'What tools don’t exist at the moment?': 'The community is doing a good job and a lot of the stuff we need is already being worked on by someone.\nETHDenver and the gas visualisation tool that came out of that.\nBecame apparent that there are places where you see red and you can’t change that and these sorts of insights are useful - do I really, really need to put this piece of data on chain etc.\nMore visual tools that you could wrap around smart contract code (that doesn’t get compiled).\nHas there been any thought around wrapper code for SCs for developer-specific tools or libraries that give you the visuals you need to understand more of what is going in.\nHaving a logger that works well and you get outputs similar to solidity-coverage and doesn’t only point out errors, but also information - showing scope and which state variable it has access to etc.\nThink about in context of Parity issues we had: the fact they tried to structure a lib as a contract could have been picked up by something like this.\nOr, in Ownable contracts, specifically printing out a report that says “The owner of this contract is the only one who can access this specific state, as opposed to other users” etc. Point out how to establish an owner (if not already set in initialisation function).',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Having a sequential getting started stuff on ethereum.org is totally, absolutely necessary.\nList of tools and resources and even an appendix-like structure of what things like Distributed Applications even mean.\nDefining use cases for those don’t wanna be in blockchain is still really hard today.\nSolidity readthedocs is very good though. Web3 v1 is much better documented too.\nThere is a disconnect between web3 v1 and latest geth: the way we were fetching tx receipts were not syncing correctly\nv1 websockets are still kinda screwy and not handled as well as they need to be.\nEnded up putting the service using the node in the same container and just ipc\nResources themselves, you really need to dig for.\nGeth has resources that are very outdated and fragmented - please can we fix this!\nNot having definitive resources and docs is a big problem in general.\nSearch github and Reddit to find random answers that I need.',
        'What are you most excited about in the short term?': 'Proof of Stake overlays will be really interesting! Bring on the FFG!!\nGetting WASM out there will be really important (and finding a use case ;) )',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '57': {
        'Name': 'Harry Denley',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Building a platform / website to educate people on how to stay safe. MyCrypto has some stuff.\nI have a Twitter poll that described this idea.\nCreate a bounty around this.',
        'Who are you and what are you working on?': 'EAL: Ethereum Address Lookup to prevent phishing.\nBack in June: chrome extension as a mini block explorer. Hover over any address, shows how many transactions it has etc.\nCouple weeks later, dedicated himself to finding phishing sites and black-listing them with Metamask and his chrome extension.\nRecently – added service every midnight to do data gathering on each domain.\nThere is a group working on anti-phishing. We share information and data through an established channel.\nWe now have a bot to run ops on domains (whois data gathering, DNS records, SSL dumps, Shodan data on the server)\nWe have also deployed an archive bot on Twitter @EthereumBadList\nMy main effort: to protect users.\nIn the start of 2017, I got into Ethereum development.\nMet team at Myetherwallet (now MyCrypto). Introduced me to other people like Griff.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'People too focused on making money and not trying to evolve the society –– moons and lambos rather than lasting change.\nWhat I’m passionate about right now: helping people who are not technologists to not lose their money.\nCould make it harder for attackers to withdraw.\nTalking to people from Changelly/etc re blacklisting addresses on exchanges.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'I have mostly used Web3.js. It has a great wiki. I haven’t had any real issues.\nThen, I went to meetups where I heard of Truffle and Solidity.\nDocumentation on setting up Testrpc and writing Solidity was not that great. Had trouble with Truffle documentation.\nSome dependencies for Truffle and the build they were using were missing.\nIntegrating Ethereum with browser hasn’t been too troubling.\nI look at Etherscan comments + MyCrypto support tickets comments.\nAnti-phishing – Etherscan blacklists bad addresses, through their moderation queue and etherscamdb.info reports.\nMost people don’t realize a Private Key should stay private\nAirdrop sites require you to put in your private keys.\nHow to prevent phishing:\nMetamask added domain blacklisting + my extension.\nI plan to do analysis using PrestoDB, finding common outputs across Ethereum phishing addresses. E.g. If most addresses go through Shapeshift, then go through Monero, can then contact Shapeshift to add their blacklists.\nBig data requires a beefy server to run it on.\nOpen-source for big data analysis of chains for fraud. I talked with Chainalysis (they do Bitcoin analysis) about the idea\nI haven’t wanted to do this – mainly because of cost & security. I’m looking into servers which could handle rate-limited requests.\nCould put this towards the anti-phishing group.\nMaking the reports public would be simpler and already helpful\nAllows me to run Mysql-style queries.\nLack of reliable faucet on testnets.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Quiknode – selling managed Ethereum nodes that are in sync. Bit like Infura.\nAdam or Paxon.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '58': {
        'Name': 'Taylor Monahan',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Money is not their constraining resource. People, hiring, management are constraining.\nBest thing for ecosystem right now is: educational, marketing, videos, tutorials, write-ups, explaining how things work.\nE.g. when your mother hears about an ICO, and they google it, there’s good resources available to educate them.\nIn the beginning, MEW was a stepping stone for people who already owned cryptocurrencies, before they started using geth or parity or etc.\nNow, this is no longer the case, there’s new people who don’t know anything about cryptocurrencies at all..\nBiggest phishing attacks they’re seeing are airdrop sites. “Free money??” Typing your private key is not a good idea.\nHow does a project responsible onboard people onto Ethereum?\nHow does the experience look as dApps become more of a thing? How do people use this?\nIn a dApp, the wallet functionality should be completely abstracted away. The user shouldn’t even know that there is a wallet.\nIf I had extra money, I would give 100% of it to educational resources, people designing infographics, videos, etc.',
        'Who are you and what are you working on?': 'Chaos. 2017 in one word.\nStarted off as a fun side project –– cofounder is Kosla – they were both working part-time.\nThen it exploded –– the Ethereum price chart is a perfect representation of MEW growth. Kosla stopped being involved after it got chaotic, because it was no longer just a fun side project.\nEcosystem started going crazy –– she started leaning in.\nTeam growth – hired 2 devs in April/May. Hired Jordan in June. Hired a person / week in the summer. Hiring a ton of support people. Got a director of security. Trying to hire Harry in full-time. Team of ~ 20.\nGrowing a remote crypto team. How to incentivize them & keep them happy. Raises don’t work in this space.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Silo’s – Slack silos aren’t healthy.\nMentioned “community of communities”\nSkype – “exchange work-group” – public infrastructure and the nodes – w/ the geth team and the nodes.\nSkype – “anti-phishing group” – setup on a whim when they saw phishing stuff come about.\n3 days ago – Ethereum blue team found MyEtherWallet clone\nEven if she’s sleeping – people are looking out for the community\nDid team retreat in Columbia / met with design firm in Chicago / they have partners in SF (week / month regularly)\nHarry Denley was the first to respond to Swarm.city multisig hack.\nWas reactionary – putting out fires.\nPROBLEMS: Security\nInternal security processes.\nAt two people you can trust each other; access is limited. At team of 20 it’s different; have to revamp internal policies; reminding people of things.\nFound 2 Slack admins not have 2fa on.\nWe are bigger target; we get password resets.\nSomeone stole her number in October but they were prepared for it. They handled everything really well.\nDNS and internal security on infrastructure.\nHired ex-director of security for Coinbase & Facebook. Works on board of Hackerrank.\nHow we hired: people who use MEW want to keep Ethereum & MEW safe. We connected on security. We had a call that afternoon.\nHe does amazing security incident response & red-teaming.\nFEW DIFFERENT SECURITY CONCERNS:\nHow we serve their code: a commit is pushed to a specific branch; that is served to github.io; then AWS pulls that code, caches the hell out of it, and that serves MEW.com.\nAll keys are rotated, and ssh private keys are kept very secret.\nmulti-stage pipeline (Github + AWS); both have multi-factor security, need Ubikey, etc.\nIt’s kind of a staging pipeline.\nPrevents bad commits or bad UI changes from getting into the website.\nHow do you QA things, how do you test things?\nWe wait 24 hours from creating a release and getting it on a live domain.\nWe have a series of tests – check that everything compiled correctly, check that all links have a rel=no-opener on them, ..\nDNS\nAfter EtherDelta and ClassicEtherWallet.\nWe have a custom thing: three services to monitor the site.\nWe serve through a CDN\nDiff the code – diffs the new website with the previous version of them.\nGets the hash of the Javascript and CSS with previous versions.\nBlockchain security\nEnsuring the user makes good decisions –– how do you alert or notify a user when is doing something wrong –– e.g. notifies you when an Ethereum address is not formatted correctly?\nHow do you build this: check the balance?\nHave microservices that have micro-databases of the blockchain.\nCaching token balances.\nOn MEW: pulls everything from Parity or Geth directly.\nCan run their infra through Cloud Formation ––\nGeth falls out of sync.\nCryptoKitties destroyed their infrastructure.\nIntel chip thing then took them 120% CPU usage, took them offline.\nFixes for Spectre and Meltdown.\nPROBLEM: phishing & supporting after the fact.\nPROBLEM: infrastructure:\nKeeping nodes Parity & Geth up all the time.\nAdditional issue: Blockchain naturally re-writes itself if you’re on a microfork. If you’re also distributing this across your own database, then you need to write code to also rewrite this. Etherscan just gave up and booted up from the blockchain from scratch.\nThis is what Infura is trying to do. They are in the same situation as MEW and Etherscan. They are under Consensys so have more financial freedom.\nShapeshift sysadmin stole money. If they had the problem, then this is a big problem.\nWhat is the cost of security in this space? How much a malicious people could stand to gain…\nWith a debit card, it’s not the same –– there is risk of getting caught, the original person gets the money back etc.\nTraditional security systems won’t work for this.\nWhen I worked at AT&T, I asked people how they trained people to not steal simcard numbers. The real cost is not cost of buying a phone.\nUNEXPECTED PROBLEM: building remote t
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '59': {
        'Name': 'Nate Murray',
        'How do you handle smart contract verification and security?': 'Wish i knew better how to do audits. Would love to know list of auditors. However, even if I could get in touch with auditors it sounds expensive.\nUse solc linter when developing.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'I started by creating my own token using the tutorial on Ethereum.org.\nI also did some of the other tutorials on the Ethereum.org page.\nRich user-facing Dapps using a modern JS web tech stack.\nSolidity for writing smart contracts and web3 for the connection to the blockchain.\nNext thing I\'m working on: solidity, truffle, javascript, ipfs.',
        'What are the tools/libraries/frameworks you use?': 'I use python for numeric analytics (not really around dapps).\nFor desktop apps I\'ll use Electron.\nFor contract development I use solidity, and web3.js for a connection to the blockchain.\nZeppelin\'s libraries for solidity.\n0x has excellent repo for js.',
        'What are your biggest frustrations?': 'Everything seems super easy getting started, especially once you understand how the blockchain works.\nThen you learn about security vulnerabilities like re-entrancy, other well known hacks, etc. Developers don\'t think about that when doing web dev.\nNewline\'s third class is \'Hack smart contracts\', and it covers DAO hack. The goal is to teach folks about security.',
        'How do you handle testing?': 'At first, getting contract working use Remix or testing framework built into truffle.\nI don\'t use Ganache.\nI really like connecting my contracts a real instance, and I like using console to connect to node.\nI do it in layers. First start developing against testrpc because its faster. Then use geth.',
        'What tools don’t exist at the moment?': 'Logging within solidity is hard, you can emit an event.\nTools around gas are hard, its so opaque.\nRemix and gas is maddening, different gas limits, might have contract call that works in one env that doesn\'t work in another.\nFormal verification; we need something better than solidity. Bamboo seems cool.\ninterested in the successor to serpent - vyper.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Tutorials are out of date.\nAPI totally changed in web3 beta.\nUnderstanding the Ethereum blockchain & program execution model.\nWhat it means to \'call\' and get (for free) or \'send\' and updating the blockchain for a fee. What it means for you transaction to be mined. This is covered in newline.\nIf high performance computing today is extremely parallel, then blockchain computing is embarrassingly serial.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Interesting smart contract platforms coming out.\nLISK dapps in eos web assembly.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '60': {
        'Name': 'Benjamin Bollen & Paruyr Gevorgyan',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'We are building a developer kit that builds a bridge from Web2 to Web3, nice interface so that people don’t need to have understand blockchain to use it.. Need to get users on the technology.\nWe have to be very pragmatic. 3 core regions to be make technology accessible by millions:\nManagement for users and development\nDefine a token for an application, how would you use it for your company?\nBeing pragmatic about scaling, a Layer 2 Solution. Not really sidechains, all value is only defined as value of ERC20.\nCircumvent boundary of the bridge with a business solution.\nWe put quite a lot of effort into this, they had 2 main concerns. Auxiliary systems, have to be natively compatible with many chains. And want to be token compatible first as opposed to be block first.\nHad a bad experience with Ethereum Permission Client, had some incompatibilities on ABI level so had to do their own tooling.',
        'What are the tools/libraries/frameworks you use?': 'From an IDE perspective: Tried to use Remix, but not so easy to set up locally. No finalized IDE. It’s powerful but not easy to set up, very complicated to set up and not so stable.\nWeb3.js Intense users, but don’t like how they handle callbacks. New documentation is not yet complete. Want more examples on web3.js. Better documentation.\nOpenOSTBase- a bunch of wrappers around the websockets around web3, make these more reliable and redundant. In production, things tend to break but this helps with that. Happy to contribute back :)\nWeb3.js is a first level API. First layer access to the technology, but want to have a more user friendly second layer that caters to the community needs. More user friendly, without having to do the same thing several times. We want a second level API, a helper or utility level API.\nWhat tools don’t exist at the moment?\nHaven’t super explored Ganache but is interested in more things done via command line. Any type of automation that can be done from the command line is cool and greatly helps with efficiency.\nBiggest thing we are missing is an IDE suited for the ecosystem. Something that could do a gas function on Remix done on runtime, you could see security things happening on runtime. Integrating Remix with a different IDE, it’s currently statically bound.\nClear explanation in Documentation.\nGeneral level: a big proponent of multiple chain universes. In OST users only really interact with Ethereum mainnet, only have tooling directed towards one chain.\nSolidity perspective, have a diagram based solution to see all the connections. Solidity codebase diagram module would be very compelling.\nHow do you handle smart contract verification and security?\nGuiding principles: observe standards and don’t invent funny ways of doing things. Trying to reduce code to smaller components and go from there. Had 3 security auditors. Cure53 reviewed contracts and all traditional architecture. Zeppelin did audit for smart contracts.\nNow working on the hardcore protocol. TrailOfBits builds a lot of interesting tools examining the bytecode. This is not an easy task. Trying to take very small steps one at a time and then go from there is the philosophy.\nThey are excited about ewasm. They respect work done with Solidity, but bytecode is the biggest thing. They have compiled with same Solidity on Mac and Linux for same thing and got different bytecode, this is a big concern.\nCompiler, assembly tools, and debug tools are all major points of interest. Could be interesting if Solidity compiles to wasm, then you have portability.\nWhat was the hardest part about learning to develop with Ethereum?\nTo set up the first private network was somewhat difficult. Didn’t use Truffle, just Geth. Geth is very powerful but is missing good documentation and had to Google.\nSolidity is good but needs better docs and better exampling. Very happy with CryptoZombies tutorials, want to see more things like this to help intro new users into the space.\nHardest thing when you deploy something is deploying a smart contract that intends to have value but not having a way to walk it back. In the last weeks running up until their deployment, did 8 dry tests with a self-destruct button. Ran this 8 times on Ropstein testnest, and then mainnet. Very interested in smart tooling to help in this process!\nMore tooling for testing of deployment. Testing where deployment happened properly to avoid situations like Parity Wallet. Had Monex with EthPM like tool. Scripting the deployment. Testing the deployment, could be a part of an automation toolset. Like fastlane for ios and android deployment.\nWhat are you most excited about in the short term?\nGetting OST to version 1.0 :) But beyond that most excited about ewasm. Also excited about Whisper and Swarm.',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Using Truffle. Have a setup where for local dev purposes are tested on one chain. At a later layer they are tested on a testnet.\nOne cool thing we would be interested in: very close adaption between local environment and staging. Having a seamless way of transitioning from local to go to staging on Ropstein/other testnet, flip a an environment variable and go from local to staging.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '61': {
        'Name': 'Fredrik Harrysson',
        'How do you handle smart contract verification and security?': 'Internal audits.\nWe are introducing a checklist system for deployments.\nPre-, during, and post-deployment\nDoing external audits on everything now. Even auditing Rust code right now.\nExternal audits are great, but the average developer cannot afford that\n***Teams have grown super fast without having time to document company knowledge so that all engineers know it*** (documentation includes process as well as code)',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Been a core dev on Parity for a few months.\nMaking the Ethereum client itself nice to use by developers.\nAlso building a solidity parser and linter\nBuilding some JS libraries for developers to actually write dapps\nTalk about the enterprise company dapp -- how did we scope, what tools, etc\nAll at a proof-of-concept stage. Probably 10 years before they can actually make it work in their business.\nI set up the docker containers for the nodes, did the documentation, and built the React App',
        'What are the tools/libraries/frameworks you use?': 'Everything, even in dev environment is containerized\nIPFS, React, Parity, ParityJS\nHave some internal tools that generate javascript ABI’s from the smart contract spec\nHave an internal CLI for deployment\nDeploys the contracts and then initializes some values\nIf you change your contract in development, re-running this tool takes a super long time, which is frustrating\nIf not already mentioned, are there any libraries you rely on regularly?\nMain library they use for all dapp development is ParityJS, and their new library called Bonds/007 (React integrations)\nParity Ethereum node has pub/sub now',
        'What are your biggest frustrations?': 'Lack of documentation is a big thing. The deploy/test/repeat cycle is unclear and kind of annoying. It’s a problem of the whole stack, not just certain libraries.\nE.g. On top you have the React app, with hot reloading. Super easy.\nOne level below you have the middleware library. Auto-generated from the ABI, and there’s some other knowledge you need. E.g. Someone clicks and approve button, which changes a contract variable and updates the UI for the owner. The business logic is both in the contract and in the JS middleware, which is hard to deal with.\nLayer below that is Node.\nIPFS client server, so the client can upload a file.\nHash is stored on chain.\nFile is stored on IPFS.\nLayer below that is the contract. Any changes in the contract bubble up, need to recompile the ABI, need to recompile the middleware from the ABI, need to recompile the React app because the underlying dependencies have changed.\nSomething that changes the level of abstraction for managing files would be great.',
        'How do you handle testing?': 'Use truffle internally for testing some contracts\nAlso write own own testing tools using Rust because we don’t like javascript',
        'What tools don’t exist at the moment?': 'Setting initial values after deploying a contract is important\nBeing able to roll back transactions would be really nice for dapps',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'How do you codify the differences between a traditional app and a blockchain app. E.g. Waiting for transaction confirmations. How do you codify it to make a good UX?'
    },
    '62': {
        'Name': 'Nicolay Wolf',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Research for cost of running WASM on different architectures and machines.\nScientific proofs on how this correlation works.\nOr also computational analysis?\nThis will be used to assign costs to Opcodes, and also know exactly why.\nParity is using eWASM’s results for this currently.',
        'Who are you and what are you working on?': 'Not developing lots of dApps.\nFoundational work for WASM:\nWASM interpreter\nRuntime environment – which allows to run wasm within any network.\nForking Kovan – allowing wasm contracts to run\nRunning wasm on private chains\nWASM interpreter:\nMain problem:\nMaking the Rust interpreter deterministic.\nWASM is not strictly deterministic –– need to narrow down to deterministic opcodes.\nNeed to ban several opcodes, e.g. floating points. Simple solution: just parse WASM and fail if there’s any floating point opcodes.\nOther option: to canonicalize the NaN constant –– you need to bring all these flags under one definition.\nOne idea: you could check after each floating point opcode –– to see if its NaN and use canonical.\nBUT this is not worth the effort, because no blockchains apps will have floating point anyway.\nOther sources of determinism: deterministic stack for execution\nWASM doesn’t enforce size of the stack ––\nWhen you get to JIT compilation of WASM, this compiles into using a register-machine specific to the hardware architecture; this process is actually deterministic.\nBut it’s non-deterministic when you go to run it.\nE.g. when a function uses a lot of stack –– e.g. a recursive function that calls itself and itself –– it can fail when it hits the stack limit of the operating system.\nThis can fail at different times for different machines. So, it’s non-deterministic.\nWe’re transforming existing WASM into this modified WASM that takes care of these issues.\nAny WASM implementation that takes untrusted code from the network needs to have this stuff done.\neWASM collaboration will be helpful ––\nMozilla has a Rust-WebAssembly group.\nGas metering – not challenging but needs to be done\nWe have tools which transform WASM from free-form to gas-metered form.\nIncludes how much opcodes cost.\neWASM has this also –– we’re taking a more scientific approach to this.\nParity simply uses the eWASM table.\nDon’t need to be super precise, just need to protect against malicious users.\nMemory also costs gas.\nSimple way is to charge for memory linearly.\nThe original idea is to charge for extra memory quadratically more given how much memory was allocated before – but you don’t need to do this anymore, because there’s new ways to allocate memory.\nGas costs are embedded into the bytecode.\nProving the correctness of implementation\nFuzz testing against various interpreters – spec implementation;\nFuzz test: allow the interpreter to run code; it should fail or do the same thing at exactly the same spots as other interpreters or existing codebases.\nThe interpreter should not panic in any case –– otherwise, malicious actor could crash certain nodes\nThey use cargo-fuzz for rust\nThere are also fuzzing tools for WebAssembly: which can generate randomized wasm modules –– can take this; put it into your implementation and the reference implementation; and see that they do the same thing.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'What is the difference between eWASM and parity-wasm?\nParity works closely with WASM ––\nParity uses the same endianness as EVM. But eWASM uses little-endian / WASM uses little-endian.\nHow does eWASM callcode, because it depends on hardware architecture?\nParity forbids some useless constructions, e.g. “internal memory” ––\nAny WASM module can include private memory; according to wasm-spec it’s not accessible at runtime; Parity forbids this.\nProjects working on WASM:\nParity, eWASM, Dfinity, Bitfury\nBitfury has Exonum – solution for enterprise blockchains with WASM runtime.\nHigher-level languages: Rust or anything else that compiles into WASM.\nThey’ll move away from Solidity. – good to have for backward compatibility (so someone making solidity-wasm compiler would be good) but not necessary.\nStandardizing WASM implementations:\nCan do renames to match eWASM or something like that.\nInteroperability amongst WASM implementations:\nWill have a simple tool that can compile eWASM to parity-wasm to etc etc.\nWASM vs. EVM:\nWASM doesn’t force you to use the 256-bit machine.\nE.g. if your computations fit 32-bit, you don’t have to deal with this inefficiency.\nWASM has strong teams behind it.\nThey’ve made a bet on WASM; so there will be resources behind it.\nBugs will get fixed by the wider community.\nWASM can be targeted by mature languages: c++, Rust, Haskell is coming, etc\nResources:\nWho’s working on Parity-wasm:\nNicolay & Sergey.\nNicolay is moving to part-time on this stuff since there’s lots of other work to do.\nThere will be another meeting about Ethereum sharding & wasm.\nThailand, end of March.\nOur libraries:\nParity-wasm: serialization & deserialization library – for changing / transforming the wasm module.\nWasmi: the actual wasm interpreter\nhttps://pepyakin.github.io/wasmi/wasmi/index.html\nhttps://github.com/pepyakin/wasmi\nWhat’s left to do with parity-wasm:\nNeed good libraries – Rust-specific – to interact with blockchain storage\nSolidity gives you this out-of-the-box – but we need to build it for Rust',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '63': {
        'Name': 'Peter Czaban',
        'How do you handle smart contract verification and security?': 'First contracts were usually for prototypes.\nI would write contract, write tests, then integration tests.\nThen would go through a review process.\nSometimes would go to an external audit.\nThis only happened for a few projects.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'I started out building some trading algorithm.\nDuring the early foundation days, there were workshops in London, and during one of those workshops I was writing a dapp using Mist.\nThen, later, I deployed a token contract for fun, and then basically started straight away with client development.\nBeen working on the core Parity client on the consensus algorithms. Consensus contracts in solidity. Proof of stake.',
        'What are the tools/libraries/frameworks you use?': 'Truffle, solidity syntax highlighter for VIM, Jupiter notebook for testing stuff\nIf not already mentioned, are there any libraries you rely on regularly?\nEtherJS\nIn Rust similar libraries like @crypto and @key',
        'What are your biggest frustrations?': 'Definitely the language and tooling. Testing frameworks.\nTruffle can be weird and does some asynchronous things that cause tests to randomly fail.\nLinking contracts together is still kind of bad.\nAre you running into problems with any of the following:\nOff-chain computation: Yeah, this can be somewhat difficult. I have seen others not being able to use it, so it clearly needs to be easier.\nCould detect patterns in a contract and recommend that something could be done off-chain.\nSometimes you want to have privacy. Solidity and compiler could figure out for you how to make particular mappings anonymous.\nState Channels: Played around with a simple one but no serious problems or anything.',
        'How do you handle testing?': 'Mostly truffle for testing. Also have some of my own custom tooling that works on RPC.',
        'What tools don’t exist at the moment?': 'Being able to run things in exactly the same environment as the deployment environment (for me, it was necessary to have a custom client that I ran code against)\nParity / Truffle sometimes behave in different ways\nBuilt a custom thing that had partial functionality to give a more consistent testing environment\nBeing able to track versioning of contracts from dev to deployment. Requires a lot of back and forth.\nPain points working with the language. I want a better type system!',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'For building the client, it was high-level architecture, but that was resolved just by having lots of conversations with people.\nWould be useful to have more documentation around here.\nFor building with Ethereum, it was Javascript and Truffle, because I already had good understanding of Ethereum at that point.',
        'What are you most excited about in the short term?': 'From experimental projects, I am interested in prediction markets and how they will work and how good the price discovery is.\nA very good application is something that doesn’t require too much throughput. Something around supply chains could be really interesting. Many parties, don’t necessarily trust each other.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Parity guys that work on the UI.'
    },
    '64': {
        'Name': 'Phil Castonguay',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Used to work for 0x, now I work as a SC dev and researcher independently.\nI was the developer relations manager at 0x.\nI am now focussing on state channels, signature-based improvements in general smart contracts, blockchain storage (utilising merkle trees and improving best practices).\nWorking with a gaming project that utilises state channels, unrelated to Raiden.\nA lot of things that could be done off-chain by simply using different signatures: for crowdsales instead of using on-chain whitelist, you send a signed message for every participant and then they need to pass that message along with sending their Ether. Used by Polymath to get around the gas costs (could cost up to $15 000 just to whitelist everyone).\nWorking with chronologic on Ethereum Alarm Clock and other secondary markets, e.g. conditional execution where I want to make sure if x happens somewhere on chain, then do y.\nRight now smart contracts don’t listen to each other and require 3rd parties to watch the chain and inform them.',
        'What are the tools/libraries/frameworks you use?': 'Using Truffle, Ganache, testrpc\nMost of the tests are not run in parallel, under-utilising my compute resources, can’t be adapted easily or extended.\nRemix for quick prototyping\nActually quite enjoy using the debugger - I find it fairly easy to use. Would be great to play with single function testing locally so that you don’t have to run a full suite to test one or two things.\nTypescript (mostly for testing)\nMostly following 0x standards - transcribing from typescript to js that make it really easy to define statically-typed tests.\nMocha, chai',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'I struggle with fuzzing: it’s very useful for when different people are working on the same standards  - so we could easily run fuzzing between entirely different teams and see if the way they implement all the functions behave the same way and make sure the different implementations of the same standard are the same. Better standardisation is key.\nWrites unit tests myself and try for 100% coverage.\nI uses Mythril and am looking forward to formal verification.\nStandards checking!! Here is a standard, put your contract next to it and check that it conforms to the standard implementation and then reuse a lot of the unit tests etc. that come with that standard.',
        'What tools don’t exist at the moment?': 'Nothing exists for state channels regarding how you pass messages and other p2p tools that allow different agents to communicate easily with each other.\nNot easy to document this.\nNo easy way to test how peers are interacting with each other and you want to run simulations in state channels.\nScheduled transactions: we need a queue to avoid race transactions, can help lower gas costs. But we need off-chain system for nodes to communicate in order to implement that.\nEasy to use and easy to test frameworks for this stuff is going to be super important.\nWould be awesome to have some kind of simulation tool for multi-agent networks of this kind (even relevant for whisper and other parts of the Ethereum network, like zeppelin doing token mechanics simulations and analysis, especially around bad agents). More of a research tool than developer specific.\nSimulator for the cross-client, cross-account signature schemes and management - right now the only way to test these schemes are to actually plug in a ledger and then test. Would be great to be able to test this from one place!\nCouldn’t make this work in Truffle, passing in byte code and passing. But then, using mycrypto or Remix, it failed because the encoding, libraries and dependencies are different!!\nVery confusing how bytecode arrays are passed in different tools and how you can convert from one type to the other, how we could concatenate a range of arguments in a single contract and then vice versa. Figuring out how that works (argument encoding) is really difficult to get right.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Coming from a non web-dev background and more from data analytics meant that everything related to async was difficult to grasp. It’s unintuitive.\nSolidity dev is not particularly difficult, but the best practices are extremely important and it is only really by experience that you learn the best and safest patterns. You need to know most edge cases and most potential attacks before you can write contracts that can actually be used.\nReading about past exploits really helps. Ethernauts is really great.\nEach opcode and how much gas it costs - there are tables online, but not updated and it takes some time to search properly the Yellow Paper. In fact, anything related to code optimisation could be really cool to see.\nEducational content focussed on code optimisation. Has not seen as much of it as he has of security and both are equally important. I.e. “Try to rewrite this contract in under 5000 gas” kind of thing. Who can achieve this, this and this with the least amount of gas.\nNow implemented: https://g.solidity.cc/',
        'What are you most excited about in the short term?': '95% of the projects are not ready for the mainstream. Mass adoption necessarily requires state channels or plasma, or secondary consensus layer like a sidechain - so that is where we really need the most development as soon as possible.\nLoom network etc. is also really exciting.\nSharding comes later, and is really exciting, but the stuff above needs to happen first.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Mostly about tools and enhancing developers lives. Finding information and answers is also really important, so ask more about the docs if you can.'
    },
    '65': {
        'Name': 'Federico & Jaynti',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Trying to work on Plasma – white paper is unspecified; it is not clear yet.\nStarted Dagger project – to get events for our UI or backend.\nUse cases:\nIf you want to send an email or notification to users.\nIf your multisig wallet has incoming or outgoing transaction.\nUI for the front-end; a multisig wallet: sent a tx and see it real-time. Make UI/UX better in Ethereum.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Websocket isn’t there. It’s not customized. Interface is not that good in geth or parity.\nI used to have my own servers running – my own laptop as a node – very painful, switched to Infura.\nCrawling Infura.\nInfura is unreliable – sometimes they miss the blockhash.\nWhy not run my own node?\nToo costly to run Digital Ocean.\nWeb3.js – nobody can use it well; very flaky. Talked to Fabian about it and offered help.\nPeople are using, but not contributing.\nUI/UX:\nEverything takes time; 15 seconds; 1 minute for confirmation. People are impatient.\nWait for notifications using Dagger.\nHow to improve:\nPoS will improve this finality. Still too long for users.\nProvide a notification to users; or email if it’s about security. If you’re buying cryptokitties, can send a follow-up email.\nEthAlarm used by Decentraland –\nStatus building decentralized notification system.\nFede has been contributing to Solidity compiler itself for over a year now:\nMostly making the experience of working with Solidity more pleasant. Life is too short.\nSolidity is quite understaffed –– only two people who are committing, who can merge PRs.\nFund more developers?\nI’ve contributed, but would love to get paid for it[a][b].\nNot many people have the availability to take part-time or full-time work at EF (Solidity, Truffle, etc etc). But are available for several hours a week to contribute.\nPromote the people contributing -> funding.\nEF has Dev Grants. Mostly geared towards bigger projects. E.g. porting Ethereum to mobile devices and wearables.\nAlso Scalability grants.\nOngoing funding to ongoing contributor would be interesting.\nBetter communications -> what different teams are building right now. e.g. with Plasma; there’s different people around the world pushing forward different implementations.\nWeekly core developers meeting – where one can participate. But how to scale that? Need different structure. There’s multiple different teams. There’s also the Gitter channels. There’s ethereum.research forums; that’s helped communications in research and fundamental infra problems.\nThere’s an issue of time; the valuable people don’t have the time to work on these things.\nSomeone watching all sources and compiles them into one place: so more people know what to work on. Proof of Work newsletter (WeekInEthereum?).\nThe fragility of Solidity tools – lack of proper tooling; e.g. comparing language ecosystem between Java and Solidity:\nLinters, refactoring code, working with modules, ...\nDebugging\nThis improved recently:\nLatest truffle version includes an embedded debugger.\nDaphubb working on new EVM with debugger built in.\nGas issues: we sent multiple wrong calls to wrong deployed functions – wasted lot of money\nIt doesn’t tell you why your gas is so high – it doesn’t say that you have a weird opcode\nPeople don’t understand what is gasPrice and gasLimit properly.\nAllow people to set one value – and set gasPrice and gasLimit interactively in the backend.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Patricio Paladino from Zeppelin.'
    },
    '66': {
        'Name': 'Alex Leishman',
        'How do you handle smart contract verification and security?': 'We refer companies to trail of bits/ other.\nFormal verification handled by specialized firms. Important contracts will/should be audited by people.',
        'Other bounties?': 'Large players funding bug bounties for public smart contracts.\nMultisig is a pain in Ethereum. Multiparty signature with a single key from an account.',
        'Who are you and what are you working on?': 'I am an engineer on the Polychain team, but come from the Bitcoin world. Used to work at a brokerage. Went back to grad school. Decent amount of experience in Bitcoin and Ethereum stuff over the years. I also have a cryptography background.\nDoing a lot of lightning stuff right now, payment channels. Spending a lot of time investing companies in the space, doing due diligence.\nBeen deeper into the bitcoin world, a bit of an outsider in Ethereum.\nI built a blockchain analytics tool called blockseer for bitcoin and Ethereum\nTaught Bitcoin/Ethereum class at Stanford in 2015\nAm really proud of the exchange and brokerage that I built in Taiwan.',
        'What are the tools/libraries/frameworks you use?': 'I don’t do much eth-dev right now.',
        'What are your biggest frustrations?': 'Expenses when running contracts',
        'How do you handle testing?': 'CI pipeline needed.\nTesting and security audits are one and the same since you’re deploying it once.\nFew contracts are heavily audited, and ecosystem is built around those smart contracts.',
        'What tools don’t exist at the moment?': 'Native chain improvements\nCasper\nGeneralized staking system where you can sell your stake via a new token via smart contracts. Bond for staking.\nProgramming tool chains for web assembly. Being able to take advantage of multiple languages like C++ and Rust and have it compiled down to WA.\nLLVM - any LL language could compile to web assembly.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'How to apply Ethereum tech and what makes sense.',
        'What are you most excited about in the short term?': 'Lightning - cheap, fast micropayments even though it’s not out of beta.\nEthereum bindings for lightning network?\nCross-chain stuff in general.',
        'Was anything easier than expected?': 'Wallets UX has improved.',
        'Who are the other people you think we should talk to?': 'Trail of Bits',
        'What are the best educational resources?': 'Andreas’ books\nEthereum wiki on Github',
        'Are there any other questions we should be asking?': null
    },
    '67': {
        'Name': 'JOHN PALMER',
        'How do you handle smart contract verification and security?': 'Linting\nCode review on my own and with other people. Check best practices from Consensys',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Web applications that interact with smart contracts, usually through MetaMask or Infura.\nWe built www.hashheroes.com as our first dive into Ethereum.\nWe built www.withpragma.com to make Ethereum development easier.\nWe built www.onhexel.com to make it easier for anyone to experiment with tokens and try new ideas.',
        'What are the tools/libraries/frameworks you use?': 'Web3.js\n0x.js\nTruffle\nTestrpc\nInfura\nRemix Solidity\nEtherscan',
        'What are your biggest frustrations?': 'The smoothest user experience happens with MetaMask, but MetaMask has tons of bugs. Regularly need to disable/re-enable MetaMask. Causes a lot of headaches because there is a lot unexpected behavior.',
        'How do you handle testing?': 'First of all, I write unit tests in javascript and run those locally.\nInteract with smart contract through remix solidity or Pragma.\nTest my app in my own UI. Check etherscan to make sure that happened.',
        'What tools don’t exist at the moment?': 'It’s not possible to bundle two different transactions together and pay with them at the same time with MetaMask.\nI wish errors in contracts were surfaced better. Generally, it is hard to know when things go wrong in contracts[a].\nGas limit\nWish I could do more within the fallback function. I know it’s limited purposefully, but I would like a secure way to execute code in it.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Biggest pain point was learning Solidity. Not knowing how everything executed.\nNot as easy to write something and test it right away, longer feedback loop.\nSolidity documentation was out of date.\nWhat would be the hardest part of teaching somebody to build a dapp?\nExplaining the difference between wallets and contracts, and explaining to them the concept of Gas and how that dictates what they can store in their contract. Explaining how computation works on the network.',
        'What are you most excited about in the short term?': 'Would be really excited to have a mobile metamask. Wallet Connect seems promising on that front.\nSeeing Dapps do live token swaps using 0x (functionally exchanging coins in an application). For example, being able to swap tokens in a game.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Antonio Juliano\nNick Johnson'
    },
    '68': {
        'Name': 'Marcus Molchany',
        'How do you handle smart contract verification and security?': 'Warning messages from Remix or solc.\nReading through Consensys best practices and making sure I use them in my contracts.\nAsking for code review in subreddits.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Made a few standalone contracts for fun.\nMore full-fledged projects are web frontend with blockchain backend.\nWeb apps use Metamask to interact with blockchain. Infura as provider if MetaMask not installed.\nWe built www.hashheroes.com as our first dive into Ethereum',
        'What are the tools/libraries/frameworks you use?': 'Ethereum: Remix solidity, testrpc, truffle, web3 JS, Infura, Etherscan\nWeb: React / redux, create-react-app',
        'What are your biggest frustrations?': 'In general project setup for the first time is difficult.\nDidn’t know if I needed geth or testrpc.\nDidn’t know if I needed to download the entire blockchain.\nAlso had problems with the documentation for solidity.',
        'How do you handle testing?': 'For contracts, I use Remix Solidity with the Javascript VM. For unit tests, I write JS unit tests using truffle. Tried to write unit tests in solidity but it was difficult. Testrpc behaves strangely sometimes.\nWhen developing a contract, I will write extra events just to make sure the right thing happened, and then will delete the events when contract is in production.\nAutomated testing?\nIncluded above. Automated is unit tests with truffle. Manual is event logging, usually in Remix.',
        'What tools don’t exist at the moment?': 'I really want a richer debugger. The one in remix is too hard to figure out[a].',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Slight paradigm shift about waiting for code to be run while transactions are mined.\nUnderstanding how state was preserved in a contract.\nFinding good teaching resources on Youtube and elsewhere.\nWhat would be the hardest part of teaching somebody to build a dapp?\nThe paradigm itself.\nThe idea that when your code runs, it’s running when a block is mined.\nCalls to your contract don’t execute instantly like in a normal web app.\nCombination of needing to use different test nets while testing.',
        'What are you most excited about in the short term?': 'More 0x relays!',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Fabio Berger from the 0x team'
    },
    '69': {
        'Name': 'Piper Merriam',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'The Hive tests –\nFramework that black-box tests EVM implementation.\nHas had multiple conversations with cdetrio on Github.\nBounty: needs clear documentation: “for your EVM to be included in the Hive tests, you need this stuff.”\nMaybe it’s not super high impact and not crisply defined\nBounty: need a formal spec for the Json RPC api.\nHave integrations tests in Web 3. Subtle differences across nodes, which make things confusing.\nSomebody needs to shepherd the ERC spec through –– most of the work is done. Dan Finlay already hammered out most of the work.\nSomeone needs to write the schema for all Json RPC endpoints.\nThis is super well defined.',
        'Who are you and what are you working on?': 'Trinity: new Python-based Ethereum node.\nPy-EVM: python implementation of EVM in python.\nSharding & Casper research team are building on this.\nWeb3.py: python equivalent of web3.js\nV4 is coming along nicely and is fairly solid right now.\nUnder the above – there are a myriad of base libraries that I’m the developer –– i.e. side-effects of the work.\nPackage management\nSimilar to Populus –– but actually the underlying core package-management structure. The solution is ready, it just needs to be built.\nIt is project that I had to cut off, but wants to pick up again –– immediately came to mind for bounties.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Package management:\nFirst piece: the spec\nERC whatever that defines the spec –– this is v1.\nhttps://github.com/ethpm/ethpm-spec\nThere is very minor adoption of this.\nThere is a v2 of this spec –– couple of tweaks to fix stuff that was wrong in the first one. This is mostly written up, needs PRs to be written and merged.\nSecond piece: the implementation.\nThere is an early Python implementation –\nhttps://github.com/pipermerriam/py-ethpm\nbut you need this in every language.\nNeeds various abstractions, for how to get deployed contracts –– returns language-specific object to you.\nThird piece: a standard –– an ERC for package registries.\nhttps://github.com/ethpm/ethpm-spec/issues/75\nStandard methods for looking up what versions of the package exist, what is the hash / IPFS / HTTP URI.\nFourth piece: implementation of the registry as a smart contract.\nThere’s an already implementation of this in the EthPM github.  Needs to be simplified.\nhttps://github.com/ethpm/escape/blob/master/contracts/PackageIndex.sol\nHaving this in Zeppelin or Dapphub.\nThe fifth piece: can have tooling + ENS nicencess to automatically deploy to registry for you.\nWeb3.js and Web3.py can implement methods to talk to packages –– can find the packages, pull them, use the right abstractions.\ne.g. you load up the Gnosis package, pull the latest version, pull it out of your web3.py, and query for your contract balance.\nTheoretical API: `web3.packaging.registry(‘packages.gnosis.eth’).loadPackage(‘gnt>=1.2.3’).contracts.gnt`\nYou get a really secure way of accessing contracts\nEach company can create their own registry.\nWhat do you need?\nTwo moderately skilled Python devs who know about Ethereum.\nTwo can keep each other in check – it’s healthier.\nCould have MVP for this in Web3.py in 2-3 months. For the full thing. Could have an alpha release.\nWhat does wider adoption look like?\nEvery etherscan contract can be wrapped up in a package.\nAt this point Etherscan becomes a package registry.\nVerifying package source on Etherscan becomes trivial –– you upload a package to Etherscan.\nNo more need for janky copy-pasting source code.\nWallet interfaces:\nMyEtherWallet –– instead of having address or ABI, you can upload the package or let you browse the registry and pick a package to interact with it.\nMist Ethereum wallet –– “track this contract” –– can show you a thing on the top that says you’re not using the latest version of this package. You get a security bonus –– to notice if you’re using an old package.\nDevelopment framework use-case for packaging!\nIs the one that’s most talked about, but is probably the last one that will happen.  It requires complex integration between compiler and on-chain assets that might be stateful.\nThe base libraries however are needed as a stepping stone to build these features on top of.\nNOTE:\nPiper can lead defining this as a bounty and setting the milestones.\n$50k/$60k feels like enough to attract attention. Can potentially get ETH foundation to fund part of the bounty.\nWeb3.py\nBeen using Gitcoin pretty heavily –– has been highly effective. Any task that they can define well, they can get done through Gitcoin reliably.\nTrinity –– Python Ethereum node\nSome use-cases will be greatly improved by third-party libraries\nThere is a solid abstraction around the database.\nGenerating a SQL backed chain db would hugely help research.\nTake an existing chain db and migrate it into a SQL db. Or just sync the chain into SQL.\nMaybe you only move the transaction and block data into the SQL db.\nAnother use-case for Trinity:\nSpin it up on Heroku – it’s an ephemeral environment – for that to be a viable way to run your own Ethereum node.\nIssue: how long does it take to initialize. In its lightest light-client mode, should be ready in sub-1 minute timeline.\nTrinity and PyEVM have the most resources available out of the things they’re working on.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '70': {
        'Name': 'Richard Ma & Don Ho',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'IDEs:\nRemix is probably the best one. No support for quick-fixes (like you have in IDEs).\nBetter support for projects.\nManage dependencies.\nCode coverage tools, to see how good your tests are. Integration would be good.\nExisting tool: run this as a separate command & get results in a web ui.\nSolidity-coverage.\nHas some static analysis tools – more would be better.\nNotes:\nWeb UI is weird. We don’t use it, because of lack of project support.\nWe use sublime text / IntelliJ.\nBetter syntax coloring like Remix would be good.\nBounty for solidity support in Vim and/or Sublime.\nDebugging\nHalf the time is always spent debugging.\nDebugging with truffle & node-js is horrible.\nHave to debug the JS and contract parts separately.\nDifferent environments.\nWe do iterative development; somewhat test-driven; We’re aiming for very good coverage.\nWhat I’m envisioning: putting a breakpoint into the smart contract or Javascript. Ideally, one breakpoint can step through all code.\nTestrpc\nUsable blockchain explorer for testrpc – to explore local data.\nWould be great for learning as well.\nStreamlining code export for Etherscan verification during contract deployment\nTypically, you have to flatten all your imported contracts, it’s a pain in the ass.\nWould be good to have a place to do this. Assures that the version is consistent.\nSometimes you need update your contract –\nTools to evolve your old contract into your new one. Only deploy the additions.\nWe had this issue in their ICO: we wanted to change the end-date for the ICO.\nThere’s a valuable data in the old contract.\nCould run into problems with consistency.\nMore than “library driven development”, would be good to have tools that generate this for you.\nMy vision: refactorings like in Eclipse; pick refactorings (e.g. can split the class, etc). This would tie into the IDE.\nDeveloper education programs\nLesson plans. Get each company to do one session\nWe went to a meetup for people who like to learn Ethereum. It was way oversubscribed.\nCould be good for recruiting / onboarding.\nWe’re putting together a “minimum security standard” after interviewing all auditing teams.\nExisting auditing tools for Solidity are poor.\nRead our Solidity analyzer: https://github.com/quantstamp/solidity-analyzer',
        'Who are you and what are you working on?': 'Focused on the security aspect of Ethereum. 3 main challenges for going mainstream:\n1) security, 2) scalability, 3) usability.\nToo many projects; audit talent is in low supply;\nSystem to allow anyone to get a high-quality audit for teams.\nComponents:\nPayment smart contract: deals w upgrades; governance\nVerification node: software to verify smart contracts\nSoftware library: formal verification, static analysis checks',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Running the client:\nLanguage support across different clients is problematic. We’ve been focused on the software verification libraries for now.',
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'NuCypher.\nKeep network.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '71': {
        'Name': 'Jay Rush',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'The tracing API across the two clients is different and seems ad-hoc.\nA common format for the tracing RPC calls, so tools such as QuickBlocks which rely on the traces would be easier to build.\nI use Parity. I can’t switch to Geth because they don’t share the same interface for the traces.',
        'Who are you and what are you working on?': 'QuickBlocks works with the Ethereum blockchain from the data side. How does one get usable, fast data out of the blockchain (as opposed to putting into the blockchain with a smart contract for example). Our work is fully decentralized (gets all of its data directly and only from the node); We take a bottom-up approach. We run for particular accounts or groups of account, not necessarily chain-wide. We retrieve and store only what the end user asks for.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Biggest concern: The idea of decentralization is being lost\nPeople are developing applications that are highly centralized, because it’s practical. Many projects promise they will one day decentralize, but I’m concerned that this will get increasingly more difficult as the technical debt grows. Many projects are deeply relient on highly centralized infrastructure (Infura, EtherScan).\nConcern: The law of unintended consequences:\nIdentification Systems\nEase of use is very enticing\nBlockchain based identity is easily applicable for government use\nBut...what happens when a “bad-actor” government or an oppressive regime requires citizens to all have unforgeable identity. How will innocent people who are legitimately against the regime hide themselves?\nI wrote about this here.\nReputation Systems\nIf we move to a world where everyone has an immutable reputation--by definition half of the population will always have a worse reputation than the other half. Due to the nature of feedback loops, this feels like a bad idea.\nConcern: The data is too difficult to use\nPer Account Lists of Transactions:\nAccounting for both incoming and outgoing external transactions is easy. Just scan to and from fields looking for a given address.\nAccounting for outgoing message calls (Etherscan calls these internal transactions) is also pretty easy. The smart contract itself initiated the message call -- send an event.\nAccounting for incoming internal transactions is very difficult. One must look at every message call generated by the entire system to fully account for all incoming internal transactions (witness air drops). I wrote about this here.\nBloom filters:\nEvery transaction receipt has a logsBloom field. These are ‘rolled up’ into the block level. Blocks also have a logsBloom field.\nAs the number of transactions per block increases (as it has done), the block-level bloom filters are getting more and more saturated. As they become more saturated, they will tend to report more false positives.\nAt the receipt level, the logsBloom are probably under-utilized (that is, they could hold more information without a large increase in false positive rate).\nThese two factors tend to make the logsBloom field both less effective than it could be and at the same time require more storage than they need to.\nI wrote about this here.\nFurthermore, the bloom filters exclude certain ‘addresses’ that, if they were included, would allow us to implement an RPC entry point called ‘eth_listAddressesInBlock(bn)’. This would be a compromise between a full index of addresses per block and re-scanning every trace for addresses if one wanted to build a list of transactions per address (which one would want to do if one wanted to audit a smart contract for example).\nWhat QuickBlocks does: Do not store either the block level nore the receipt level blooms from the raw data. Instead, at each block, build an enhanced bloom filter which (1) includes every address involved in the block including those used as ‘data’ for internal transactions (ERC20 transfers and air drops), fill the bloom filters to a predetermined level (configurable, defaults to 200 bits), and when one bloom fills up, create another one at the same block. Result: significantly less storage devoted to blooms, consistent level of false positives resulting in less overall searching, ability to quickly answer ‘is this address used anywhere in this block’ with perfect fidelity.\nInefficiencies\nSept-Oct 2016 DDos transactions make requesting traces astronomically slow. I wrote about this here and here. Suggestion: easier way to identify (and skip over) dDos transactions.\nWhen you use ‘eth_getTransactionByHash’, the RPC does not return the transaction receipt. In order to get the receipt, you must later call ‘eth_getTransactionReceipt’. You need the receipt to understand if the transaction was ended in failure. Twice as many calls to RPC than needed. Suggestion: staple the receipt to the transaction with an optiona
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'QuickBlocks is Ethereum-centric; works on Ethereum derived chains. Not Bitcoin.\nEvery 15 seconds, QuickBlocks polls for data from the node, it then\nOptimizes the data for quick, later retrieval\nOptionally, stores the data efficiently\nNext time user asks for a block, retrieval is faster (it’s a cache).\nHow QuickBlocks started:\nI wanted my own transactions – for my 40 different Ethereum accounts.\nAccounting for movement of funds between all accounts.\nInitially – was pulling data from Etherscan. But why do this through a website?\nDesigned to run on a laptop which forces us to stay decentralized\nApplications:\nWhen you develop smart contracts, you get event data from web3. But this only give you generated events. In-error transactions are not seen because they do not generate events\nCan analyze tokens.\nCan do smart contract monitoring / early warning system\nShould write monitoring code which watches blockchain – if it notices something weird, your contract can react. If the DAO had had events in it.\nWas involved in the DAO. Stunning how little information was available. It took many hours for anyone to notice the hack because no-one was actively watching\nI did some analysis of DAO hack. The actual hack is very obvious in the data on the very first block.\nWould appreciate intros and connections to other projects.\nThe code is ready to go. Will be fully open sourced and properly licensed soon.\nQuickBlocks won  2nd place at NYC Consensus 2017 hackathon.\nThomas Rush founded the Philadelphia Ethereum group.\nWe welcome speakers from around the world -- please contact me if interested\nA bounty I would pay for––\nKumavis was talking about blockchain data on IPFS or Swarm or another content-addressable distributed storages.\nCould build a blockchain that is a chain of IPFS hashes.\nA marketplace of block data could grow.\nInfura –– could pull the block data from Infura.\nI don’t care about the hexadecimal raw blockchain data – I only want the transaction data fully-parsed – stored on IPFS.\nFrom an email follow-up (possible bounty I might pay for):\nFor a particular range of blocks (preferably in the millions), and using a given list of Ethereum account addresses (one of which will be an ERC20 token, addresses to be specified in the bounty), provide a definitive list of all internal message calls and external transactions along with, at the end of each block, a reconciliation of each address’ ether balances. Additionally, at the end of each day in the block range, provide a list of token holders along with each token holder\'s token balances. The source of the data must be provided. Using 3rd party websites (such as Etherscan) is permitted, but the source of the data must be disclosed. Preference is data provided directly from a local Ethereum node.\nThe given list of address will be interrelated and taken from a prominent ERC20 token system. One of the addresses will be an regular, external account. Another will be an ERC 20 token smart contract. A third will be a multi-sig wallet. The deliverable will be JSON data showing all internal and external transactions for each address. The delivered data must ‘parse’ the transactions to the smart contracts (that is, the transaction’s input data field must be converted from the hexadecimal to “the language of the smart contract”. The deliverable will be a collection of JSON files formatted using a jsonlinter with specific settings which would allow for diffing results with other methods. Performance metrics will be provided as well. The results must be made open source so as to provide the smart contract auditing community with a ‘gold standard’ of community vetted results to be used for testing/verifying new or existing off-chain auditing tools/software.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '72': {
        'Name': 'Yann Levreau',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Hard to make links between tools.\nIf you want to make a DAPP (truffle and remix, metamask for front-end), how can you aggregate all tools or write documentation?\nSwarm integration for Remix?\nCurrently if you “import”, it imports from the Swarm gateway –- it’s a basic integration, and can be improved to be really cool.\nFrustrated developing on Swarm. Building Swarm integration, but not usable in production.\nWas trying to fix a bug in Remix - but related to how they import Swarm file -- had trouble fixing bug because emix used Swarm gateway which was offline.\nSwarm not in production environment yet -- looking forward to this.\nWeb3 library\nIn Web3 have send transaction method - no wrapper around it or other functions that people can use, and use more safely. Would like to see web3 safe send transaction (locate transaction in EVM to check if transaction passed. If its fine, transaction is sent, and if not there is a warning).\n“Wrapper around Send Transaction Function”\nPossible to develop transaction which fails. If you want to develop a transaction, you first have to send/execute it (but don’t want to lose money). Execute transaction locally, wait for trace and then debug it. Think this is what Truffle is using.\nContract’s with specific values: in code, write maximums to revert transactions - can this be added in front-end (ie. limiting contracts values so when transaction is sent there is a check beforehand so you can be sure you don’t make mistakes).\nWould require changes in solidity to provide this functionality to web3',
        'Who are you and what are you working on?': 'Working on dev tools for the Foundation for the last 2 years.\nWorking on Remix for the last 1.5 years.\nWorking alone for the last bit.\nOver the last 6 months, there are more developers. Team is 4-5 people now.\nIuri Matias: dev of Embark –– he’s on the Remix team.\nMain scopes of work:\nImproving the UX.\nThere’s a Remix chat where some people were saying they were using it to deploy mainnet, and I was shocked, since this was not the intended use-case initially.\nUX for people to use Remix and deploy contracts, and not make mistakes.\nAdding static analysis\nThere is a new tab-based layout.\nThere are several modules.\nSplitting Remix into different modules\nCan now write contracts, debug, deploy, do static analysis –– this used to be all in one app. Now it’s modular, so you can use these pieces in different apps. E.g. can use static analysis in VSCode.\nHe was in touch with Roan Blanco, developer of VSCode –– he started to integrate the debugging part of Remix as a plugin. Might do the same for static analysis.\nRoad is adding the static analysis.',
        'What are the tools/libraries/frameworks you use?': 'Focussed on Remix and improving the UX:\nRemix is an entry point for users\nBut it’s hard to use for beginners.\nIt’s hard to use if you don’t know blockchain or the tech behind it.\nThere’s documentation and videos on youtube – still hard to use.\nIdea: do UX user interviews\ntake a beginner developer or new user, and let them use Remix (or other tools), check out what the main flows are, what are their main questions,\nThey have two people – who come from front-end dev. When they started 6 months ago, they didn’t know blockchains, so their feedback was helpful.\nThere are three kinds of blockchain users\n1) front-end dev: wants to use the blockchain to build UI, but doesn’t care about contracts.\n2) contract developer\n3) administrator: not writing code, but still needs to call contracts or send transactions to them.\nRemix is not focused on front-end devs right now. They’re not targeting these people. They target contract developers or admins who “use” contracts.\nIs there a tutorial, or a beginner contract that it initializes:\nYes. There is a “ballot” contract – but it’s kinda opaque and hard to understand.\nDocs: remix.readthedocs.io\nHas a quick start page.\nNeed to improve: onboarding for “administrator” users (above). So they can use Remix without making errors.\nTwo bounties\nUser testing for various blockchain-user personas (above).\nMaking tutorials or videos for beginners using Remix.\nBuilding the static analysis tab:\nNeed to add more modules.\nThere will be a way to add plugins in Remix\nLet’s say you are an external contributor, you’ll be able to add code, but the code won’t be in the Remix github, but in its repo and it’s added as a plugin.\nE.g. Solium integration.\nWe are architecting the plugin API with the Solium team.\nAnother example: Oyente –– we’re integrating it as a plugin.\nPotential bounty in the future:\nWriting good documentation around this. We’re all super busy devs, and need people to help with documentation.\nLast week – someone created an Electron app for Remix –– self-driven contributor; would be nice if they can post Github issues and have people contribute and get rewarded.',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '73': {
        'Name': 'Gustavo Guimarães',
        'How do you handle smart contract verification and security?': 'Here in Berlin I have worked with solidity,berlin and they are amazing. Do really comprehensive audits.\nHave also used formal verification tools: most often Mythril, sometimes Oyente.\nI am also aware that the invariance checks etc. are also created by humans, so might not be entirely comprehensive.\n3 levels of checks: write code, write tests for the code, pass to another engineer to check, then formal verification tools, lastly do the audit.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Blockchain engineer, working in the space since 2016. Mostly as a freelancer, helping companies solve business problems using blockchains.\nMiddle of this year, started Samsara Protocol. Started with idea of selling real estate on chain, and decided to use a raffle based system to do this.\nAbstract idea from property to raffling all kinds of assets.\nSmart contract developer in general.',
        'What are the tools/libraries/frameworks you use?': 'Use Truffle heavily.\nStill a long way away from good debugging tools.\nUsing Remix out of habit, especially to check and step through opcodes.\nRemix to dig deeper into what is going on with my solidity code. Especially the debugger there to dive into the EVM.\nHave got used to the debugger here, but it is still so obscure when something throws an exception and difficult to find out why.\nI have developed some intuition for this, but it’s really, really difficult for people just beginning.\nNo break points!\nUse open zeppelin as reference for smart contracts - have worked on some educational projects with the Zeppelin team.\nNo issues with this. Haven’t looked into zeppelin_os yet.\nBut the idea is quite interesting - upgradeability and on chain libraries are cool.\nTruffle-flattener library - make all your modules into one file. Use this to deploy, rather than doing it file by file.\nReact for frontend stuff.\nWeb3 to hook it all together.\nWebsockets (wss) are tough to work with. Having difficulty connecting to them through the infura nodes.\nOverall, really happy with the new version - it solves a lot of problems, particularly around signing transactions safely.',
        'What are your biggest frustrations?': 'Syncing my node to the chain has become really difficult. I used to do this a lot last year, but now I use Infura because the node is so heavy/hard to maintain and it is just easier to do it this way.\nNot at all good for fast development cycles.\nI have learned to embrace how slow testing can be because everything is async there.\nFor the raffle system I need to draw a random number, and right now this is kind of impossible in the EVM. The holy grail would be to produce a really random number at compilation time that cannot be tampered with by miners etc.\nRight now I am just using an oracle to do this.',
        'How do you handle testing?': 'I test in JS - unit tests mostly.\nOn average the ratio is 15:1 testing to smart contract lines of code and this can cause things to be quite slow, but it’s still good practice and seems necessary for immutable contracts.\nOverall, quite happy with what comes out of the box with Truffle.\nHave only added await async calls to make things easier to read. Have some Mocha extensions added for the same reason.\nPrefer readable code, rather than fast code, especially when it comes to testing.',
        'What tools don’t exist at the moment?': 'Would be nice to have a tool that could get bytecode and re-engineer it into solidity code.\nSometimes I want to check if a function or some functionality and, if the contract has been deployed but not verified, it’s not really possible.\nOpen source block explorer.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Really excited about the research around scaling Ethereum. I am myself working on side project to do state channels.\nThere was an awesome lecture at EDCON, and was super inspired by David to try it out myself.\nNot necessarily in the next 3 months, but there are so many ideas out there that it is bound to be exciting for anyone getting exposed to it.',
        'Was anything easier than expected?': 'I was pleasantly surprised the first time I connected to a node using Infura, to the point that I decided then and there to not use my own node.',
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'What I love about Ethereum is that most of the code is out there in th open - so I go and read it.\nI often go to the Aragon repos and check out what they are doing and how they do it.\nAlready mentioned the open zeppelin library.\nThis is how I learn - just keep up-to-date with the best teams and the latest features the Solidity team is rolling out.\nThe solidity readthedocs is pretty good.\nI have written some blog posts myself about how to do things in the Ethereum ecosystem. I sometimes go back to these and they are often very helpful.',
        'Are there any other questions we should be asking?': null
    },
    '74': {
        'Name': 'Scott Wright',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Just simple stuff - proofs of concept.\nWorking through course material\nBuilding a token and a very minor escrow app\nTimed auction.',
        'What are the tools/libraries/frameworks you use?': 'Remix\nGeth obviously\nSolC for compiling\nYarn is (apparently) standard now for js\nIf not already mentioned, are there any libraries you rely on regularly?\nWeb3',
        'What are your biggest frustrations?': 'Hasn’t happened across too much yet! Been working in solidity and I find it pretty easy. But how scoping works is confusing.\nThere was a situation where I was trying to refer back to something and it was doing something weird and I had to dig and find out that behaviour of memory depends on what SORT of memory its being stored to.\nSo, if you get a lot of JS developers, you need to explain how scoping works in JS and how solidity is different in that sense.\nHow much of those memory problems are a thing with solidity, or the EVM?\nA linter would be very useful!',
        'How do you handle testing?': 'Automated testing?\nThere’s an IDE that I’ve used - Remix. Provides an interaction with Geth, create test accounts, and then I use that UI to launch a test application on testnet, play with it, see if it works…\nI WANT an automated test suite, but nothing out there right now.',
        'What tools don’t exist at the moment?': 'Automated testing - I want a testing suite, a whole tool that is entirely focussed TDD. The work really corresponds to that. Clientless work with many test iterations.\nA lot of uncertainty around how gas works.\nWhat is it exactly, how does it get used, how do you optimize for it?\nThe basic idea is fine, but the details when you’re building stuff are very hard to find out\nWhat are the best design patterns for dealing with it, the strategies?\nAlso, you come up against issues when there’s a withdrawal attack vector, where you try to send ether to them, and there’s some sort of callback function and etc.\nThere’s a design pattern that works around that, but my level of knowledge is just that someone TOLD me that, but what other things do I need to be aware of? How can I find out more? These are open questions for me right now.\nWould love a list of things where I can go through check marks and say “OK, I’ve followed x and y” and I’ve watched out for the following 23 possible issues / attacks.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Would have been that initial setup of the development environment, and beginning to build a mental model of what’s going on. Just the setup.\nFirst thing is a soft thing - understanding the difference between a distributed application vs a centralized server application. I’ve taught people some basic blockchain concepts - it doesn’t always make sense to people right away.\nThe action of calling methods externally on a contract - I kind of understand how that works, and then wait a cycle. There’s a bunch of haziness around how calling methods works though.\nAnd then the exact amount/ability that a method has to change a contract - how much can it do? What are patterns where I could manipulate and kill the contract?\nAwesome thing - I love working with apps where there’s no account or login, it just works.',
        'What are you most excited about in the short term?': 'Vyper!\nHave big hopes for truffle - has a lot of the build suite things that I need.\nAnother thing that’s missing right now is a better IDE, solidity based coding environment right there, so my workflow is that in terminal etc.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '75': {
        'Name': 'Felix Feng',
        'How do you handle smart contract verification and security?': 'Contracted security auditing firm before launching to mainnet and did it internally.\nIntroduced to firm through investors\nZeppelin and Consensys security etc. are super backlogged and can be highly expensive.\nTried automated tests for quantstamp but their compiler solidity version (4.2.3) wasn’t supported.',
        'Other bounties?': 'Debugger\nMore free automated formal verification\nList i.e. Aggregated “Awesome Ethereum” for security (blog posts, tools, etc.)',
        'Who are you and what are you working on?': 'Founder of Set Protocol, wrote all the smart contract code/unit tests\nAims to build collateralized baskets of tokens. Bundle the world. In a tokenized world where tokens lie behind everything, we need to create abstractions that remove mental overload, improve transaction efficiency, and handle large amounts of tokens in general.\nJust released token sets dapp for bundling/unbundling token sets. First use case- investment vehicle/product. Javascript library similar to 0x for interfacing with their smart contract code.',
        'What are the tools/libraries/frameworks you use?': 'Internal javascript library in Typescript for UI  interfacing with their protocol (bundle/unbundle)\nUses 0x ABI gen for automatically generating typed objects\nTruffle for testing/ compiling\nTruffleHD wallet provider repo\nInfura for deploying code to Ropsten testnet, hitting services all the time. Easier to deploy to testnet.\nFor deploying to mainnet, they use Remix.',
        'What are your biggest frustrations?': 'Truffle migrate on main net\nWeird configuration where generated code doesn’t match source code.\nReturns error on Etherscan that the code doesn’t match.\nHas to do with Truffle compiler...\nTherefore I have to concatenate code myself and deploy using remix.\nRevert/invalid opcodes don’t tell you much, logging is pretty much ineffective, code must be recompiled every time.',
        'How do you handle testing?': 'Started with truffle tests\nThen converted tests to typescript for type safety (avoids host of potential errors, useful for building FE library as well) and used 0x ABI gen\nAim for 100% test coverage (~95%)',
        'What tools don’t exist at the moment?': 'Debugger. Especially as contracts start linking to each other, stack trace gets more important.\nOpen source block explorer for any chain.\nLot more typescript tooling. 0x started the movement and built tooling around it.\nPeople are building their own deployers/compilers. More standardization need here.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Truffle needs to be easier for beginners. Tough for first-time hackathoners...\nGoing into source code. Things are early and not handed to you on a platter.',
        'What are you most excited about in the short term?': 'Ethereum proof of stake\n0x open source tools.\nMetamask replacement by Toshi- needs to be more tools than just metamask.\nZeppelin OS. Upgradeable proxy contracts infrastructure.\nToken curated registries, oracle problem, bringing data from off the blockchain to on the blockchain. Token rebalancing from winners to losers could use TCR’s.',
        'Was anything easier than expected?': 'MVP versions of product are easy. Handling all the vulnerabilities/optimizations/edge cases take 90% of the time.',
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Consensys Academy\nTruffle/Solidity documentation and source code.\nStack overflow',
        'Are there any other questions we should be asking?': null
    },
    '76': {
        'Name': 'Simon Jentzsch',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'CTO of SlockIt.\nDaily standups like any other startup, making sure all our tools work correctly\nPart of day consists of update on new tools, libraries and their respective stability. Assessing trade-offs is difficult and time-consuming work.\nConsulting work, experience with real customers\nConnecting IOT devices to the blockchain\nEnergy Web foundation, smart meters\nSmart contracts for data incoming from IOT\nDetermine what  type of hardware they should use\nBuilding universal sharing network (USN) in-house.\nConnect IOT devices, access control, rental and sharing settings\nLaunched MVP on Testnet and inviting beta users. Planning on deploying to Mainnet.\nPublic repo containing architecture and contracts\nAll smart contracts will be publicly available after security audit\nUse Kovan since its compatible with most clients. Also on Rinkeby.\nUsing Parity for tests, but interoperability between clients is lacking badly.\nGives and recieves audit\nFirst, internal security audit\nThen, number of experts from different teams.',
        'What are the tools/libraries/frameworks you use?': 'Start with Truffle - mainly for testing and setting up environment\nDoesn’t produce/support typescript\nExtended version we produced and use for\nTypesafe contracts based on solidity contracts\nThrows errors on incorrect smart contract types\nUsually write tests with Travis CI, for all three browsers (GETH, TestRPC, Parity)\nUse Remix for debugging\nWish we had a more stable and easier to use debugger!!\nTest RPC vs Ganache\nMany tiny differences (output syntax, JSON RPC error messages, etc.)  between clients makes testing very hard between clients\nRPC Specs need to be tightened up so that we can communicate with them from whichever framework, write tests easily and actually understand the error messages that come back.\nNot specific enough, too much room for divergence\nWeb3 library is trying to limit this',
        'What are your biggest frustrations?': 'IDE integration\nThere are tools and plugins for different IDES. Being able to use Solidity just like any other language would be really nice\nDo just the basic stuff right.\nCheckers/linters exist but they’re all over the place. Integrated into IDE, not via CLI, would be helpful.\nPackage manager for existing libraries needed that could manage packages and bundle them in a secure way\nManage standards better\nNot just syntax highlighting, but code-assist/completion and deep syntactical and structural understanding.\nWeb3 Libraries\nLatest updates broke all our tests, so reverted to fixed versions',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'Scalability is long-hoped for and looked forward to ;)\nMainnet as main authority,. For different devices, different chains.\nCurrent work around could be  to use bridges (parity)\nMicropayment, multiply party, state channel Solutions like Raiden up and coming, but not ready yet\nContracts that pay only for your devices from a certain account\nThey currently use libraries and packages to avoid security issues',
        'Other domain specific questions?': 'IOT security challenges?\nUse blockchain to enhance security by using smart contracts for access-control\nDevices are dumb, smart contracts grant access\nDownside if how to get a stable connection which is secure and able to run on low hardware specs\nClients that are able to run on small IOT devices is a big challenge.\nWe’re developing light client IOT device, Incubed - not just light client but IoT client for microprocessors etc. Can do verification without even syncing with headers.\nDevices that need to sync just a few times a day, in unstable WIFI env.\nNetwork of full clients running on servers. Incube randomly choose nodes out of the networks. Send JSON RPC request, answered with signed block hash/header.\nIf you send wrong block hash, then they lose their deposit.\nHow do you store a private key on IOT device?\nIOT device pvt keys generated from unique aspects of that specific hardware so that each device can easily generate its own key without transporting it anywhere\nPaying for gas from each device is a big challenge.\nTrying to integrate with uPort and others for app key management',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Having people around, trying new things, debugging existing ones. Most important is talking to and working with people who know more than you do - there is no substitute for that it seems.',
        'Are there any other questions we should be asking?': null
    },
    '77': {
        'Name': 'Fernando G',
        'How do you handle smart contract verification and security?': 'I always try to keep myself on top of existing known vulnerabilities and the new ones. I have a repository with proof of concepts of most of them, and I run unit tests demonstrating the bug and the fix, in that way I have a practical view of the known security bugs. Then I try to audit my contracts using the knowledge I acquired and the tools available, mythril formal verification, mythril analysis, manticore, porosity',
        'Other bounties?': 'I think anything related to ease the whole lifecycle of developing Smart Contracts is a good candidate. A good IDE (or plugins for existing matures IDEs), with integrations to common services and tools like embedded 1 click debugger, 1 click deployment with builtin interaction with on chain contracts would be a game changer.\nAnd like I said, a good project that can make average users to use Smart Contracts without the need of handling the private key, secure it, go to an exchange and verify their identities to get ether, then use complicated processes to do a simple thing would help a lot to gain adoption, which is very important (even if the network and technology is not completely ready at the moment for that)',
        'Who are you and what are you working on?': 'I am a developer, working in London for the last 4 years, I love coding in general, but also security. I am joining ConsenSys next week and I am working in several side-personal projects, including the solidity-graph-debugger',
        'What are the tools/libraries/frameworks you use?': 'Well, it depends, when I build tools related to Ethereum, I tend to use the Java ecosystem (Java8, Maven/Gradle, Spring if it is a web application, etc).\nWhen I am writing Smart Contracts, I use truffle for building and testing, intellij with Solidity plugin as IDE, Ganache, Mythril for formal verification, etc.',
        'What are your biggest frustrations?': 'Maybe it is my fault, but I would like to see more tooling around other languages (especially Java, that is the one I am more comfortable with), but I know some people who are working on it at the moment, like Conor and his team from blk.io, they are doing a great Job.\nI am not a huge fan of JavaScript, and most of the modules are more maintained in JS (which does not mean better code!), so sometimes I have to adapt and use them. Anyway that\'s not a huge deal, I am not that extreme and I am fine with using any tool that can help me to achieve whatever I have to do',
        'How do you handle testing?': 'For unit testing I use truffle, I write JavaScript tests, it works great. I use Mythril if I am auditing my contracts, I identify some really important invariant and I write a little script to formally verify it, and Mythril is great for that. Manticore can also do that, but didn\'t have the time to test their scripting APIs (something I have pending)',
        'What tools don’t exist at the moment?': 'Good question, there is a lot of ecosystem that has to be created. The most obvious thing, would be a graphical debugger that is what I am building, but also dependency management tools, good IDEs (intellij solidity plugin is cool, but like everything right now, it\'s a bit green), better documentation tools, clients for pretty much everything, an easier way to interact with contracts for the average non technical user...',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Scalability improvements. I want sharding and PoS (if you can call that short term, maybe I am an optimistic person)',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Hmm not sure if you spoke to Bernhard Mueller, seems a pretty interesting person to talk to.\nSecurity people in general. Also Conor Svensson, interesting to see what he is trying to do regarding with tooling in general and adoption of different ecosystems',
        'What are the best educational resources?': 'I would say no books, because they get outdated 1 week after the release, read the official documentation and start straight away to test things by themselves. Fight and fight more, then read again the documentation to grasp things that were missed the first time, then keep practising and do that in a loop until things start to make sense. Then I would try something like Cryptozombies, to learn a practical point of view, and solve Capture The Flag challendes, like OpenZeppelin Ethernaut or capturetheether. With those you will learn basic (and complex) security issues which are absolutely essential to be able to deploy anything in the mainnet',
        'Are there any other questions we should be asking?': null
    },
    '78': {
        'Name': 'Dandelion',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'SourcCred - bounties and reputation for open source work.\nEarn ethereum cred - reputation in the eth ecosystem for different projects\nFair distro of tokens based on who developed the project\nAnalyse history and collect social feedback to refine the process\nCurrently a “regular” web front-end and back-end with plans to move the backend to blockchain in near future after proof-of-concept, doesn’t want to host a centralized server\nI am also currently trying to correctly map Github identities to Ethereum addresses. Was thinking about developing an ad hoc key-based style proof, post a specific gist so that you prove you hold the account.\nIPFS & filecoin separate business layer (fs and file retrieval) from incentive layer. Same thing with SourceCred. We want tokens to flow according to a software infrastructure graph.\nTokens flow according to software dep graph\nNeed a fair transparent way for who determines credit for a project. How can we create tools for determining who earns credit in a fair way? Using algo and data collection. Been in Node ecosystem to parse data out of Github. Try to implement Pagerank on files, pull requests, function level, etc. Using TensorFlow for cred.\nConnect GH ids to eth addresses eventually',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Highly adversarial environment makes it hard to feel safe. Wants to develop SourceCred outside of blockchain as much as possible before moving to Ethereum as late as possible. A misstep in the Ethereum ecosystem could have disastrous effects for project.\nIt would be really great to see better documentation and more static typing in the ecosystem.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'At core abstractions layer. If SourceCred depends on Foo library. Every time I mint SouceCred tokens, I want to give SourceGrain token to not only contributors to SourceCred but also the Foo library. But in Blockchain it is very difficult to Iterate over all of the objects.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'CryptoZombies really improved my intuition.',
        'Are there any other questions we should be asking?': null
    },
    '79': {
        'Name': 'David Wolever',
        'How do you handle smart contract verification and security?': 'Front end: nothing really\nDapp: went through intense reviews.\n3-5 people on a call and would go line by line through the code\nAlso hired a couple external audits\nEven after all that, found one bug right before launch (a few days before)',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Been working with Spankchain team. Combination of state channels and smart contracts.\nAlso worked on smart contract for ICO auction.',
        'What are the tools/libraries/frameworks you use?': 'Vim editor, truffle. Metamask.\nSwitching over to onenet, using something called Vinos. Under the radar.\nVinos going to support state channels natively. Will be a little bit less terrible than Metamask.\nTrouble with metamask.\nInterface not well documented.\nDoesn’t have promises.\nHad awful error reporting.\nDon’t know when someone closes metamask transaction. Had to write logic that says if they’ve clicked the button 3 times and we haven’t heard back, give them a tooltip. No documentation for that kind of thing.\nVinos will be iframed, not chrome extension.',
        'What are your biggest frustrations?': 'Gas limit: No problems with this really.\nMetamask was giving absurd gas prices because another service was getting it wrong.\nState Channels: Have had a pretty good experience there. Biggest time sync is blockchain to database synchronization. David wrote something for using state channels with SQL. Insert transactions from a block, insert signed messages, and get balance for account.\nBiggest frustration is getting block messages into the database.\nWrote a tool called Chainsaw that does this. No mechanism for a reorg.',
        'How do you handle testing?': 'First, use Truffle for unit testing.\nSeries of scripts for blockchain scraping. Call Truffle to send transactions to testrpc. Script connects to testrpc to make sure the state has been correctly changed.\nManual testing by running multiple test auctions. Just actually going through the process 40 or 50 times over the course of a week. Started on testrpc and then did it on a testnet with more test users. Even tested on the mainnet a few days before the real auction.\nTests on the mainnet actually revealed new problems that weren’t revealed on testnet\nBecause there were hundreds of logs per block on the mainnet, it was too many\nHad to go through and make performance better on mainnet',
        'What tools don’t exist at the moment?': 'Need a tool like metamask supporting state channels (Vinos will fix this)\nSo hard to get insights into what’s going on in solidity.\nDebuggers are really hard to use.\nDebugging tests is a matter of just guessing why assertions failed.\nSolidity interpreter would be awesome without having to compile each time, would make development much faster.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'No real breakdown of how everything works together\nWeb3 talks to a geth node which has the blockchain state. What does the contract do? How do you deploy it?\nGeneral how stuff works.',
        'What are you most excited about in the short term?': 'Ours. Spankchain.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Why are people building dapps instead of just building them with a normal database or something?\nWhat is your motivation for choosing a blockchain based project, instead of just a Postgres database?'
    },
    '80': {
        'Name': 'James Young',
        'How do you handle smart contract verification and security?': 'We had multiple audits at multiple periods of time. Had to just to make sure that to have a semblance of security, had a bug bounty. Left a subtle bug to make sure audit was legit.',
        'Other bounties?': 'Getting mainstream users onboarded. Informed by practical problems, just getting ETH. Cold start problems. Ways of getting around this, using Gas Relay. What would be interesting iswhere dApps, applications have pre-funded. EIP-186 where you can have the dApp pay for gas.\nIt’s going to delve more into identity based solutions. That’s what really needs to be worked on, that first-time UX down so a mainstream user can use this. We need to figure out the UI/UX. One click Amazon shopping is the standard. We have to solve the problem.\nThis breaks down into two things, part of it is a multisig wallet solution. It’s very scary and you have 0 Eth and you’re interested in Ethereum, don’t lose your private key! This is like Internet cash, but I’m used to forgetting my password. Fund recovery for a new user. Once you have value, you can learn about private key, about mnemonic. Funding something that makes multisig easy to use.\nThe cold start problem, not having them to pay the initial gas costs when they don’t have value. If you can solve those two things, mainstream adoption.\nI think having a dedicated layer 2 talks specifically could be interesting. Layer 2 solutions are the solutions that scale. Get more Layer 2 solution widespread. And then a lot more collaboration between projects. Projects that need Layer 2 solutions could invest into a fund that is a common platform so not everyone does their own solution. To keep it very practical, want to incentivize everyone to share the knowledge. Could start a DAO to automate this, could get some funding via token inflation. They are working on this DAO on the side but there is still some aftermath for the DAO,. Providing this structure to have people come together on projects as opposed to one project.',
        'Who are you and what are you working on?': 'Work primarily with Spankchain, doing state channel research/implementation. Also worked on Adtoken, first production release of TCR.\nI can preface this by saying this was all informed initially by experience with online ads. In online advertising, I had to deal with scalability and scale. Helping run a video advertising exchange on the supply side, on a slow day did 4-5 billion events a day. In online advertising, had to start at scale.\nBefore online advertising was in gaming, needed to be 100% in uptime. Game used AWS/EC2 at the time.\nLooked at Ethereum, had scaling problems. Looked at all these initial options early on. In Adtoken, for the TCR did the groundwork for serving ads. Had concept of verifiability.\nKnew about the concept about state channels, was waiting for them. Ethereum community does a great job at being able to explain things and have docs, but lack of production projects.\nOpportunity with Spank chain to hit the ground running and implement into production, learn by doing. Alternative approach with state channels and dove right in. So much invaluable info you learn when you have contact with reality.\nComing tools for layer 2 tooling. Need to have these standards, but don’t quite exist yet.  This is all informed by practical implementation.\nAlso work on a DAO that helps multiple projects that need state channels.',
        'What are the tools/libraries/frameworks you use?': 'We use Truffle, and Ganache on the web3 blockchain side of things. On traditional web2, use node, Kubernetes, Docker (traditional scaling pipeline).\nEtherscan to verify transactions\nIt’s a lot of looking at Github issues. Have to support multisig contracts.\nOn the front-end React/Redux.\nRely heavily on Infura, Metamask. Have their own state channel wallet, users fund SpankWallet with Metamask and then they open these other state channel with card.',
        'What are your biggest frustrations?': 'When I’m doing unit tests in Truffle, not knowing where the revert came from. Have been talking to the Mattis network, they focus on plasma. If the contract throws or reverts, it will tell you the line number.\nWriting the smart contracts is 20% of it, testing is more like 80%. Being able to have better clarity and visibility on the tests would be great.\nMy biggest fear or anxiety would be knowing if there are any bugs are in the smart contracts. Trail Of Bits has been working on a Fuzzer, having tools like that is would easy a lot of frustration.',
        'How do you handle testing?': 'I test and retest. Wrote the auction contract in Spankchain, the only payment channel auction ever. The contract itself was 150-170 lines (including comments). Had to document well and had 3 audits, but tests were over 2200 lines long.\nThis became a distraction. Had to create a testing DSL. Had to test for success and for failure. Had to test for strange modifier behavior. Had to lock myself in a room for a few weeks and think of every possible scenario and test for itself.',
        'What tools don’t exist at the moment?': 'I wish and a hope there is bachelor’s in blockchain. In blockchain, you have to know legal, economics, game theory, some coding, etc. Here‘s the best curriculum so you can understand for yourself, is this mechanism design good. Some cryptography. Need to be able to give people the fundamentals. Need a broader view, not just technical.\nThis is why it’s so fascinating, you can go down so many rabbitholes. It’s intimidating, if you had a set course curriculum with the basics. Here it is, it’s starting to happen. Cryptoeconomic primitives. Teach people beyond the code. Allow people to draw their own conclusions.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Knowing what Gitter channels, Slack channels, places to go. And Online identities. Knowing who to trust. Being in the Consensys Slack channel, that’s so great as there’s lots of sharing of knowledge there.',
        'What are you most excited about in the short term?': 'Actually having micropayments be a thing and scalability be a thing. Everyone talks about Floppening, where Ethereum overcomes Bitcoin. But that floppening fo me is if that txs offchain are more than the onchain transactions. That is what is really exciting. Now we won’t have a limit, we busted through that limit. Hope to happen this year.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'I would actually talk to operators that have successful startups. There is interest there. Learning how to run and operate a businesses. This is what is also really needed in the space. There are analogies to the beginnings of the Internet. How DNS became DNS. This would inform, this history you don’t really hear about. How did social games become mainstream? Was FB leveraging off of Myspace? What were those key learnings there? Ethereum as a technology, getting a healthy mix of people that have been there and drawing analogies and lessons at a higher level can be extremely useful\nList of successful operators that have done 2-3 exits in companies before. The space can move very fast. Needs to be rounded out by successful operators and implementers. Instead of writing papers, let’s implement it. You get the real life pain points.\nState channels don’t matter if you are still like, “How do you begin?” Can be more open about failure, be more honest about this. Harder to learn from success than to learn from failure, good to have a safe environment to learn from failure.',
        'What are the best educational resources?': 'Depending on the background, a lot of it is hard because the docs get stale so quickly. Hard pointing them to the right version of things. When people ask, they just train themselves. They build their own blockchain developers, he teaches Solidity classes.\nDon’t point people to any one example, his tactic is to give them a couple of books like Radical Markets and 5,000 Years of Debt. If they are willing to read that he is willing to spend his time with them.',
        'Are there any other questions we should be asking?': 'Human behavioral things, what holds your feet to the fire? What is that motivates you? What keeps you on track? What are you doing now and how do you hold onto this track? It’s sometimes better to have these constraints, so when you don’t have these things what makes you sure that you’re on the right track?\nSee a lot of projects waiting to see, but have to implement. Have to have the real-world conversation instead of academics. Need to get this feedback and keep going. People wanted to play Farmville just because it was up, this is what informs him now. For Spankchain just gotta launch, then you know what you really need to solve.\nSo ask why are you doing what you are doing!'
    },
    '81': {
        'Name': 'Doug Hoyte',
        'How do you handle smart contract verification and security?': 'Trying to keep everything as simple as possible, reduce attack surface, minimise dependencies, the usual. We have a pretty comprehensive test-suite, and perform white-box invariant tests after every interaction.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Doug Hoyte, working on sportcrypt.com, a sports betting exchange. I\'ve also consulted on a few other ethereum projects.',
        'What are the tools/libraries/frameworks you use?': 'web3.js, ethereumjs-util, solc, testrpc, parity --dev, metamask\nOverall it\'s pretty easy to get started, which is nice. For dislikes see next question.',
        'What are your biggest frustrations?': 'Docs are usually out-of-date, plain wrong, or both.\nAll libraries, docs, interfaces, etc have ossified around the web3 API, which is basically a wrapper around a trusted RPC interface to a node, so it may as well be a client to a centralised system\nVery difficult to provide good UX with ethereum \'nonce\' system: having multiple transactions in flight at once doesn\'t work the way people expect them to (\'nonce\' is a misnomer anyway -- only way to cancel a transaction or resend with a higher gas price is to reuse a nonce, something you should never do with cryptographic nonces)\nEverything is built with polling in mind, even when a push notification system would be superior. Need to poll infura constantly since you can\'t subscribe to events. Inefficient (wasted bandwidth/CPU) and bad UI (users aren\'t notified as soon as possible when something happens)\nOff-chain signature APIs are inconsistent across implementations, in multiple different ways\nWhen signing data in metamask, users see a bunch of gibberish unicode characters. Proposed solution was to make a \'good enough\' schema instead of, for example, re-using the solidity ABI\nThings not directly related to consensus don\'t seem to be well designed: The \'sandwich\' model of complexity (where you assume someone else will come and do the hard-work of integration so you don\'t have to) hasn\'t worked great so far\nMetamask silently pushes down updates to users without their consent, occasionally breaking things (and of course they could steal all your eth if they ever wanted to). They also have a built-in censorship infrastructure now (supposedly only to use against phishing sites, but potential is there for anything)\nTestnets like rinkeby make you sign up with your facebook account or something to get coins\n Solidity compiler misses some trivial optimisations, has odd limitations like max number of local variables, and handles memory vs. storage qualification in subtle ways',
        'How do you handle testing?': 'Custom test harness, could never figure out how to get truffle to do what I needed',
        'What tools don’t exist at the moment?': 'Hmmm, a good light client implementation so everyone doesn\'t centralise around infura/etherscan, although that ship has probably already sailed',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Working around web3/metamask bugs',
        'What are you most excited about in the short term?': 'Building out our product, watching adoption grow. In terms of ethereum itself I think there is a lot of legacy stuff and bureaucracy that will impede improvement, so I\'m not holding out much hope there. Time will tell of course.',
        'Was anything easier than expected?': 'Solidity is supposed to be completely awful so it came as a surprise to me that it was actually fairly reasonable',
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Not sure. Solidity docs are OK if you are technical',
        'Are there any other questions we should be asking?': null
    },
    '82': {
        'Name': 'Ricardo Guillerme Schmidt',
        'How do you handle smart contract verification and security?': 'No major process. “This function should do one thing. Only that. If it can be used to do anything else, that’s a problem.”\nI saw that the Parity library didn’t have the owner set. But I think other developers should write the code so that this is impossible.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Development of smart contracts for Status.\nCan also do some web3 integration with javascript, but I have not really dug deeply into that.\nI want to work on DAO’s that have delegation proxies so that you can trust an expert to vote for you.\nOraclize but too expensive.\nTrueBit but not available.\nZokrates or some other solution also a possibility.',
        'What are the tools/libraries/frameworks you use?': 'Microsoft VS code, Git, Remix for manual tests, Truffle, Parity.chain for testing, Mist & Parity on Ropsten for development\nI gave up on Ganache - too much variability between that and live environments.\nIf not already mentioned, are there any libraries you rely on regularly?\nNot really, mostly backend.',
        'What are your biggest frustrations?': 'Being unable to returns strings nicely. Regularly blocks me.\nMy project GitPivot connects git to the blockchain and generates tokens for commits. Needs to store git usernames, but can’t. So instead has to store a hash.\nBut that means he has to ask the user for their username each time so he can check the hash, which is a bad user experience.\nScaling!! Scaling is actually the biggest problem. If Ethereum nodes can’t handle the state it will all become useless.\nAre you running into problems with any of the following:\nGas limit:\nYes. Not for deploying, but when users are adding to big arrays it can get complicated.\nOff-chain computation\nYes, same problem with arrays, with on-chain computation. Sokrates? Not sure if zkSnarks will be able to solve this.\nState Channels\nHaven’t used them before.',
        'How do you handle testing?': 'Automated testing?\nFirst develop the smart contract.\nManual test with Remix is the first step.\nEthercamp IDE was really good, but now it’s too old.\nThe new tool for Eclipse might be good but it’s only on Windows.\nWhen it looks like it’s working, write some truffle javascript unit tests.\nUsually spotting bugs happens in manual tests and truffle unit tests are just for making sure it’s good.\nRemix debugger is very useful, but it’s missing some features.',
        'What tools don’t exist at the moment?': 'Would be very good if VScode had the same thing that remix had - i.e. an actually Integrated IDE.\nWould use only remix, but it’s horrible to use with multiple folders and things like that. Remix is only good at small projects but wants it for big projects. Connecting with RemixD can often mess up all your files.\nSolidity can’t return arrays or variable length values. Knows there is some solution with assembly but it’s too ugly.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Not sure, not actually difficult. If you understand decentralization, it’s easy. If you don’t, then there’s no reason to try it.\nImmutability makes you more cautious when going to production.\nWhat would be the hardest part of teaching somebody to build a dapp?\nDepends on the user. If the user is good in JS, it would be understand the fundamentals of the smart contracts.\nExplaining fees & immutability.\nBiggest problem is they don’t see the whole picture, just get 1 part of blockchain technology.',
        'What are you most excited about in the short term?': 'Excited about Golem. I really want to use it because I have a powerful GPU at home that is not mining. I want to do something useful, not just use my GPU for mining.\nLove Ethereum for proof of stake, that was my main interest in it at the beginning.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Jordi Baylina, James from Status, Luis Cuende from Aragon.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '83': {
        'Name': 'Richard Ramos',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Smart contract developer at Status, also working a lot on Embark.\nBackground: I came out of TransUnion and the financial industry.\nI write smart contracts mostly related to SNT use cases: Tribute to Talk; smart contracts to control spam; a set of contracts related to identity and recovery and to allow users to register their Status ENS domain.',
        'What are the tools/libraries/frameworks you use?': 'Embark, obviously!\nNot just a framework for web applications - it lets you create properly decentralised applications.\nYou can build an app and then forget about the process of uploading to distributed file stores and setting up a lot of the infrastructure.\nEmbark uses web3js-1.0, which is useful because there are a lot improvement encapsulated in that library. I like the style of coding you have to use - promisfying everything, every communication with EVM is done asynchronously.\nVS Code locally and Remix to test contracts.\nWorking between them and copy-pasting between can be a real hack though. So, I start on Remix and once I am sure it is working and stable enough, I move it into VS code.\nSometimes I also use Truffle because I like the debugger they have.\nA lot of tools from the JS ecosystem: node-js, React, webpack.',
        'What are your biggest frustrations?': 'Working with MetaMask and your local node/test environment is often unstable and connecting it locally can lead to strange issues that are very difficult to debug, as your contracts work fine in tests, but then fail arbitrarily in the browser.\nNot having breakpoints in Solidity is hard. It would be awesome to able to see more clearly the flow of the code and follow things through the stack with some suggestions/explanations.\nLast week, when deploying some contracts through Embark, it just read my contracts as interfaces and so didn’t compile them.\nNot an Embark error - it comes from solc, because there was an error about the “stack being too deep” which happens when you have more than 16 local variables (which is not well documented anywhere that I know about).\nThe error behaviour in general is weird and difficult to follow. Better documentation around this area in particular is very much needed.\nSeriously though, most of my frustrations are related to debugging.',
        'How do you handle testing?': 'Mostly through unit testing in Embark. I created a new feature for it (not yet released yet) that lets you create a small scaffold for the unit tests you need for any given contract.\nAfter executing that functionality I can then populate the code for each individual test, and this saves a lot of time.\nNot really using verification tools right now.\nHandle code coverage with solcoverage.',
        'What tools don’t exist at the moment?': 'If I want to build things that are secure AND cheap to use, this is really difficult because we don’t have an existing scaling solution.',
        'Other domain specific questions?': 'Let’s talk about Embark further. What do you see as the most important tools you’re building?\nEasy storage/uploading to Swarm and IPFS. Swarm in particular as IPFS support has been there for a long time.\nSwarm has unique support for DApps and we are building some examples that use state channels and other interesting scaling solutions being developed.\nThese sort of example projects (well beyond SimpleStorage) allow us to put ourselves in our users’ shoes and understand what can really be done and where the pain points most often are.\nEmbark is planning to integrate the Remix debugger as well.\nTracking how the value associated with variable changes in the course of running specific transactions etc. is a very important feature for us.\nEmbark also has Whisper support, which can still be improved a lot.\nRight now, we try to simplify the experience of using Whisper, but it therefore lacks some flexibility.\nI am not able to specify a private key that links to a public symmetric key. E.g. when working on the gas relay node (a node-js service that subscribes to a whisper symmetric key) and we have to do it manually using the web3js library because the whisper functionality provided by Embark specifies the keys automatically and it is not currently possible to change them.\nWhat is the gas relay node you mentioned?\nIt lets you perform transactions without actually holding Ether. It works by sending a signed message (through Whisper, or p2p, whatever). The signed msg is parsed by nodejs service and it will use the ETH that service has to create that transaction for you and will deduct the amount of required tokens from the account that sent the signed messaged.\nIt is ready to be demoed internally, but we need some additional input.\nThis solution needs to be included in the app, the desktop app, and perhaps even in the mailserver nodes, so requires a lot of feedback from our different teams.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Status!!!\nPlasma cash is really interesting and I follow it closely. Omise Go is an impressive team.',
        'Was anything easier than expected?': 'Learning solidity and writing your fist smart contract is actually very easy.\nIt’s the edge cases  and optimisations that are hard ;)\nThere are some good best practices that you can follow pretty easily and all the big hacks have been well documented, so researching why they happened is easy and will teach you a lot about writing better and more secure code.',
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Subreddit for ethdev and stack overflow, as always.\nCryptozombies is cool.\nI learnt SO MUCh about smart contracts from ethernauts.\nI like reading HackerNoon on Medium - there’s some interesting stuff there.',
        'Are there any other questions we should be asking?': null
    },
    '84': {
        'Name': 'Bob Summerwill',
        'How do you handle smart contract verification and security?': 'As good as that gets right now, there are various guides to best practices. Consensys has a really good one. Leaning on Zeppelin, Consensys Diligence, zklabs. Fairly small amount of people that have expertise, real dearth of people.\nConsensys Diligence was super swamped for requests right at the start. Pay someone to stop working on their project.',
        'Other bounties?': 'Work for GUI’s, development tools for GUI’s. Can we get to a level where Visual Studio/Visual Studio Code/ Atom? Interactive debuggers is absolutely #1. Single stepping through it.\nOn Truffle, you can do with smart contract debugging. Because you don’t have external inputs, you’re not reading from inputs, no keyboard. The path is completely deterministic. Scrubbing backwards is quite simple, rewind is entirely possible. That kind of tooling could work.\nBack in the day, there was Mix. Was a sort of debugger, but their own IDE really. But how much maintenance was this? But this is where Remix came in. With Truffle it’s all low-level, command liney stuff. Need to add value for normal developers.',
        'Who are you and what are you working on?': 'Been involved with the Ethereum community since 2015. Worked for Foundation, and then for Consensys, then at Sweetbridge. Bootstrapping current efforts.',
        'What are the tools/libraries/frameworks you use?': 'Most of his work has been on the platform work itself or on the community side. Truffle and Remix are the leading things. Embark and Populus, a little bit. Metamask, very important. Mist not so much, it really needs a bullet in the head. Was a good idea 4 years ago. No one wants a desktop browser.\nMist was meant to have a dapp store and everything, and was meant to configure it. Brave killed it. MyCrypto and Metamask were really underestimated at the start.\nInfura is absolutely essential, that’s just fabulous.\nLooking forward to in-browser client. Parity bridge that pushes block data into IPFS, JavaScript for IPFS. In-browser client, lightest of light client. Don’t reconstruct the whole thing locally. Primarily Metamask driving this. Ride on top of libp2p instead of devp2p.',
        'What are your biggest frustrations?': 'Where we are at now is a transition between amateur and pro. Needed for a long time but starting to see now. We’ve got so far in research and development stuff and volunteer time. But we really need to get professionals in. Software engineering side, community, and business side. And a million other things. UX is a chasm between where we need for mainstream clients. Unusably terrible for end users!\nSame on the development side. We’re not even in 1993 in the web, we’re in 1986 and a core dump could happen at any time. Swinging samurai swords around, do not give these swords to normal people!\nEven on the developer side, layers and layers of shit. Far get to where we need normal development. As we’ve seen through hacks and flaws. Can’t write backbone of the banking industry.\nFormal verification is not done for normal software. To get to mainstream, we need to be composing pieces more. If you’re an iPhone developer, think of all of the tooling you have available. Everyone is building their own bricks still in the space.\nBut this has happened before, we want this to be as simple as writing a web app. IDE single stepping. Automated builds and quality checks. We need to be it as simple.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'Interactive debugging. Truffle and Remix have started to have little bits for that. What you really need is a nice GUI debugger. VSCode or Sublime, you need step-in debugging. Visual Studio would be ideal, step in and step out.\nProfiling, gas counting. Doesn’t exist. Anything with performance or gas counting, metrics and analysis stuff.\nOn FIFA, what was so incredibly involved was doing instrumented builds and then delta. Seeing memory use go up by this amount, objective before and after measurements. Having this instrumented data to go in. Automated builds is like “Whoa, what the fuck happened to the gas count there?” Some change was made. Costs are a huge consideration for smart contracts.\nStandard libraries and frameworks. Need to not have people writing low level stuff, it should be common and it’s hard and easy to fuck up. People shouldn’t be writing this. The primary innovation for mature languages are the standard libraries, don’t write a string class or math class.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Where are the tools? There’s nothing, going back 30 years ago.',
        'What are you most excited about in the short term?': 'I am excited about preaching about the end of tribalism which seems to be working a bit. Don’t have to argue about blokchchain being a thing any more. But how can we ship? But need to get a version where people can build real things.\nSupply and demand are starting to marry up. Central banks have done their proof of concepts, great for stock markets. Getting to answers for scalability, privacy, and useability. We’re at the state where we interview people on what do we need? For the last few years, if you solved scaling then maybe we’d be interested. We need money! Now we have it. We’ve got people pairing this together to get stuff done.\nOn the enterprise side, loads of blockchain jobs. If you like the area you can get in and have that stability. Becoming another part of technology. Success is when blockchain becomes boring. Then we’ve won.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Some universities starting to teach, Consensys Academy, have to cross-train.\nGet involved in a local meet-up, it’s all about the people. Find people near you that are already involved. Nothing else is mature enough. Hardly any books, just got Mastering Ethereum coming out at some point. This will be legitimately useful at some point.\nIC3 are doing a bunch of stuff. An increasing number of people in the community are starting to do more technical blogs. Demonstrating legitimacy by demonstrating value.\nRic Burton has been fantastic recently, great blog posts.',
        'Are there any other questions we should be asking?': null
    },
    '85': {
        'Name': 'Yaniv Tal and Brandon Ramirez',
        'How do you handle smart contract verification and security?': 'Instead of statically linking contracts, you find the library that already has what you want and you call functions on this blockchain. This is pragmatic from the gas standpoint but raises security questions on the dependency.\nSo far still statically including everything, would like to do more including things dynamically. But not comfortable with existing solutions.\nBut stuff we include statically we have to audit ourselves.\nHaven’t deployed anything on Mainnet for The Graph, but are talking to firms that specialize in auditing. Want to do a full rigorous auditing.\nDo a little bit of social proof, use things widely used by the community.\nFor dependencies, still just in development so have been pretty loose with it. Have been using OpenZeppelin, widely used 3rd party libraries.',
        'Other bounties?': 'We need to ask, what are the barriers to dapps going to mainstream? Scalability, and how to make transactions fast and cheaper.\nUseability around things like wallets, like Metamask, is also a problem. As people have to approve things, it’s not a good UX. Not designed for microtransactions or to handle cases where a bunch of transactions only go to 5 dollars worth of ETH. This would be tooling. Plugins that would support payment channels (like Next) and state channels with the recent L4 paper. This needs to be integrated into the UI/UX. Set the budget, authenticate in an easy way (finger print), and in a secure way to have it do a payment channel and eventually state channels.\nLastPass or OnePass, weird to me that they haven’t moved into this space yet. Status could solve this on mobile. 99% of mainstream people won’t use Metamask.\nFor Open Source Block Explorer, the big problem is around collaboration. Problem is how to solve the problem around the nodes and to incentivize this.',
        'Who are you and what are you working on?': 'Yaniv and Brandon from The Graph, query protocol for getting data off blockchains and storage networks\nFocused on research and protocol design\nThe issue is that Ethereum nodes do not maintain a lot of indexes, if you’re using the JSON RPC you can’t run queries on smart contract state. A lot of time, people need to transform the data. The way they’re storing data onchain is not how to they want to pull that data out\nThe Graph is a Layer 2 protocol that sits on top of Ethereum that builds those indexes that makes all that data available via GraphQL.\nGraphQL has become really popular in the web and mobile community, substantial improvement over REST API’s. Gives you flexibility so you can make changes to UI so you don’t have to make changes to the back-end. Having this query language on Ethereum is great.\nGraphQL is a natural fit for blockchain. If you don’t have a centralized infrastructure in the mix, GraphQL can make a lot of sense for this.',
        'What are the tools/libraries/frameworks you use?': 'Been using Truffle for Solidity. Remix on occasion. Etherscan on occasion. Looking at already polished contracts.\nUse Parity and Geth, use Parity a lot as a Rust shop.\nAll over the place with IDE, Atom, Visual Studio Code. Atom not good for writing a lot of Solidity code, only one guy is maintaining the linter for Solidity for Atom.\nHaven’t been doing so much dapp development recently. Are looking into ZeppelinOS contracts, started using Aragon for contract codes.\nStruggled with Aragon at ETHBA hackathon, they made a lot of changes before the Hackathon that threw them off a lot. Overall like APM, spins up IPFS node, like the upgradeability.\nAPM (Aragon Package Manager) is not just for Aragon contracts, is statically linked to contracts on the blockchain.',
        'What are your biggest frustrations?': 'Artificial limitations in Solidity, number of parameters in a function call, or variable length for things that you are returning. In 2018, really? I think this is the Solidity Compiler, don’t think this is the limitation in the EVM. The stack limit is the other thing, you can’t write good code that is abstracted well, you have to write stuff around the compiler.\nGetting data out of blockchain is hard. Our project is trying to solve this for the community.\nFor Ethereum, lots of parts of the engine are getting swapped out. Move to Vyper, will this be the preferred language? Area has a lot of churn. With move to eWasm, will there be a move away from EVM? Need clear guidance on how things are going to be upgraded. For eWasm, have a development environment for this so people can experiment on this. Giving people a way to experiment and to run on things.\nSolidity events are just sugar on top of low-level logging capabilities that EVM provides. Solidity events are just a convention that is built on top, but unclear how this breaks abstractions on top of the EVM that isn’t part of the EVM itself. But this might not be able to be represented across different languages as they move to them. How much will break when people move off Solidity?',
        'How do you handle testing?': 'Write a lot of tests, try to make them as comprehensive as we can.\nThink we use Truffle for writing the tests, all in JavaScript. Home rolled their own utilities. Don’t have anything for test coverage.\nFor end-to-end testing, would be nice for good tooling for this. Kind of pain in the ass to test other systems that interact with the blockchain.',
        'What tools don’t exist at the moment?': 'Pretty common for people to develop contracts locally but don’t really know what gas costs are, and then they deploy to testnet and Mainnet and are surprised. Compile time tool for estimating gas. Embark 3.1 has a Profiler :)\nI know people are working on different types of debuggers, that’s a big one. It works well in Remix, but if someone integrated this in Atom that would be pretty great.',
        'Other domain specific questions?': 'How have you found working on Aragon, esp. APM?\nOverall, I like the direction of APM, with a registry that also spins up the IPFS node with artifacts auto-deployed on it.\nThe devil is in the details and it can be quite complex, but it’s a promising direction.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Plasma stuff. Obviously early days, but we want to see Plasma stuff ship.\nState channel stuff is still interesting. Obviously sharding and eWasm. All scaling stuff.\nWe like Vyper, which is a more functional, formally proven language.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'CryptoZombies, used to send people to Zasterin which had some good courses. But not sure if this was updated in a while\nLooked at a bunch of Truffle tutorials.\nBig picture stuff, podcasts like Unenumerated. Preethi has some really nice high-level Medium posts.',
        'Are there any other questions we should be asking?': null
    },
    '86': {
        'Name': 'Sina Habibian',
        'How do you handle smart contract verification and security?': 'A bunch of upfront discussions and security analysis.\nThen writing tests.\nSecurity audit, bug bounties\nThen, we will run a beta on the mainnet',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'I started in January or February of this year, and used a tutorial on Medium for creating a voting system.\nInteresting because the tutorial was already out of date by that point.\nWorking on TrueBit. A few smart contracts:\nTrueBit core incentive layer: tasks workers who do computation off-chain\nWeb-assembly interpreter in solidity\nBuilding a bridge between dogecoin and Ethereum\nHaven’t really started on any front-end stuff for these things.\nInteractive Coin Offering protocol that TrueBit did',
        'What are the tools/libraries/frameworks you use?': 'Vim with solidity syntax highlighter, truffle and travis for tests\nRunning into problems with truffle on the current project\nZeppelin’s libraries for safe math and tokens. Using some JS state machine libraries for the client.',
        'What are your biggest frustrations?': 'Super slow cycle due to testing.\nAre you running into problems with any of the following:\nGas limit: Yes, for local testing enforcing gas limit.\nOff-chain computation: Yeah.',
        'How do you handle testing?': 'Truffle and Javascript unit tests\nFirst person to build the contract didn’t use truffle, so built his own complete testing system.\nBuilt own testsuite because truffle wasn’t configurable enough for my needs: it was running into issues as the complexity of the smart contracts grow\nDeploy things to testnet. Though it’s true that there is a limited amount of benefit from deploying to testnet. It that doesn’t really test stuff like vulnerable attack vectors or incentive misalignments\nBetter to do real testing on the mainnet under a public Beta, using real ETH',
        'What tools don’t exist at the moment?': 'Testing is so important in this space, but testing is so painful and so slow.\nNo good debugger!!\nSlow testing and debugging slow down your whole cycle.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Wrapping my head around potential attacks and edge cases in smart contracts.\nWhat would be the hardest part of teaching a software engineer to build a dapp?\nIncentives and economics angle is the hardest part to teach people, but likely the most important.',
        'What are you most excited about in the short term?': 'TrueBit because it gives you the ability to run any piece of code and get the result back no matter how long it takes\nArtDAO\nSmart contracts are self owning but don’t have any intelligence.\nAI’s are evolving and learning, but they don’t have any resources.\nAI creates 5 pieces of art and puts them up for auction. Sees the prices.\nKeeps making better and better art, and the goal is to maximize how much money it has',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'Dan Finlay'
    },
    '87': {
        'Name': 'Truffle Team',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Set of tools: linters & coverage tools\nCritical, have mostly been worked on volunteer basis.\nNeeds ongoing support; needs to adapt to changes in the stack (Solidity, Web3, …)\nShould be platform agnostic, should not assume that people are using Truffle, should work with dapphub.\nLeonid Logvinov wrote a 0x code coverage tool.\nbounty: making a next-gen coverage tool, that can be consumed by any platform or into your tooling.\nCode coverage is absolutely critical from a security point of view.\nThe existing system is fragile, and only has two devs working on it part-time (?)\nPeople to talk to: Christopher Gewecke, Alex Rea (works on Solidity coverage), Leonid Logvinov (0x coverage tool)\nChris wrote the code coverage tool before joining Consensys, it’s a volunteer project.\nThere are also more sophisticated audit tools: Mythril by Consensys (Bernard Mueler), Oyente maintained by MelonPort is another one.\nTracing / gas-profiling?\nWe would like to add this kind of stuff to ganache.\nRemco Bloemen working on gas-profiling.\nBounty: support for hardware wallets in Metamask\nWeb3 has their provider engine.\nBetter key management support on the web3 level.\nMetamask also wants to have Ledger support.',
        'Who are you and what are you working on?': null,
        'What are the tools/libraries/frameworks you use?': 'Chris:\nThe closer you are the foundation of the stack, the less pain you feel.\nWe probably cause the pain.\nThere’s a disparity between demand for infrastructure, and supply of engineers working on it.\nI love web3 & Solidity – good open-source projects, fantastic engineers.\nWhat I do day-to-day: development of Truffle.\nNick:\nDisparity between engineers using the tools & engineers using them.\nThe demand for mature projects has stepped up\nThese tools, Truffle included, are struggling to handle mature projects, mature teams, mature practices. It’s great when people are building proofs of concept though.\nThe requirements are coming in pretty fast\nWhat I do day-to-day: Truffle debugger; development of Truffle',
        'What are your biggest frustrations?': 'It’s downstream on Etheruem and Web 3js; upstream from developers\nNeeds to act reactively with what comes down the pipe from web3\nNeeds to act proactively to help developers\nSolidity develops faster than we can go through their process & do their QA.\nNeed to bump the version –– but solidity sometimes introduces breaking changes –– 4.11, 4.12 – e.g. visibility modifiers; but hasn’t happened in a while.\nA range of projects: sophisticated projects (Aragon) but also people who don’t know how to use npm.\nWe’ve been conservative about how we upgrade\nWe’re making solidity stricter and stricter; but we don’t know what kind of crazy stuff people have written.\nSolution: try to make the tool configurable; based on plugins; users can make it into their own thing.\nMaking the compiler configurable.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Integration between truffle & ganache?\nWe’d like their tools to provide a cohesive set of tools.\nTakes time to build and just figure out what the requirements are.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Currently we use Gitter. Every Truffle member spends time in there.\nBut we don’t think Gitter is the right tool for Truffle’s entire community support\nNeed to see what messages were missed.\nPeople find bugs or issues that just don’t get serviced, we fall through the cracks\nNeed a better way to announce to our community\nWe have a mailing list\nWe can message on Gitter – but people miss the messages\nThere’s some first-class moderators on there.\nDetailed answers are so helpful and seem to come through often in places other than our docs, which is hard to manage.\nStackoverflow is a great resource – look at questions on stackexchange to find what things are creating the most problems for users – where the anger is.',
        'Are there any other questions we should be asking?': null
    },
    '88': {
        'Name': 'Preethi Kasireddy',
        'How do you handle smart contract verification and security?': 'In the past, OpenZeppelin. Don’t think we’ll use them again because they are a bit pricey.',
        'Other bounties?': 'Testing and debugging!\nKey management stuff.',
        'Who are you and what are you working on?': 'I’m the founder and CEO of Trustory, an app that’s built on the blockchain. App for users to create stories, and stories get validated using a cryptoeconomic game. Stories are claims that people are making!\nBefore that, I was doing independent development and was an engineer at Coinbase for a while.',
        'What are the tools/libraries/frameworks you use?': 'With Ethereum, for Trustory, we will write smart contracts in Solidity but maybe also make extensive use of Go.\nTendermint Consensus engine to build our sidechain with.\nOther Cryptolibs TBD.',
        'What are your biggest frustrations?': 'Not enough standard libs. Creating a dApp, the stack is not well-defined. The ecosystem is very early with a lot of breaking changes and versioning problems.\nScalability, privacy. People are still figuring it out. Very few people are working on sidechains.\nNot great documentation.',
        'How do you handle testing?': 'For JS, Mocha/Chai. In the past, used py-ethereum. For now, TBD.',
        'What tools don’t exist at the moment?': 'Debugging. We don’t use Truffle, and if you’re not using Truffle, it’s kind of impossible to debug your contracts. Truffle is not the future, it feels very restrictive. If you’re not using Truffle it’s difficult.\nTesting. Surprised that there is no native tester for Solidity yet. Good examples to test using pyethereum or some other library.\nKey management and key generation, for people that are not security experts. Right now, some people are using BIP39, some people are using other stuff. It’s a mess. We need to decide what the standard is and make the examples around it.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Everything. Nothing follows a standard.\nBiggest thing was debugging and testing. You don’t have a proper debugger, life is hard. Deployed the contract every time, had to fix it every time, very manual.',
        'What are you most excited about in the short term?': 'For my app to launch!\nExcited for Casper, for Proof-of-Stake',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Head of Tendermint, Zaki .\nAntonio Juliano CEO of dydx (have previously spoken to Brendan Chou).\nNadav of Dharma (interview #19)',
        'What are the best educational resources?': 'Read the Ethereum source code, read the Solidity documentation.\nI learned by reading source code. Read Ethereum for depth, and then read Solidity docs. Looked at as many contracts as Solidity contracts as possible.\nTop projects: 0x contracts, Gnosis contracts, Augur contracts. Looked through top projects.\nSome people look at Consensys tutorials, but I personally don’t like them because they lock you into their ecosystem.',
        'Are there any other questions we should be asking?': null
    },
    '89': {
        'Name': 'Alexey Akhunov',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Unification of testnets[a].\nRinkeby & Kovan are still incompatible.\nI wanted to write this myself, write Kovan implementation in Geth?\nI hate that everything in the smart-contract ecosystem is written in Javascript – e.g. Truffle. People then use truffle bindings in production.\nNative go tooling. Native go contracts.\nI tried to do javascript auditing. And it is virtually impossible without safety of types. There’s a lot of dependencies; it’s really hard to check everything.\nSpecific: where the web-server is written, not in JS, but in a compiled language: should bind directly to the smart contracts, instead of going through JS bindings. Use go-bindings.',
        'Who are you and what are you working on?': 'Been in Ethereum since the beginning. Was following the PoC. Mined few blocks on his home computer.\nInitially ran geth, then parity, then geth again.\nGeth said it would be more like a library.\n6 months ago, moved to doing Ethereum dev full time.\nDid security audits – gets tedious – smart contract are usually short. But comes with more stuff – server-side, etc\nNow: playing with the go-ethereum code, trying to optimize it.\nPeople talk about sharding, Casper, etc will fix everything; but that won’t solve everything without optimizing everything.',
        'What are the tools/libraries/frameworks you use?': 'Geth.\nCan pass in --cpu-profile\nUses basic stuff that comes with Go: PProf.\nGo has in-built tool to open this file.\nCan generate dominator tree -> whole graph of traces vs times. Shows which nodes are dominating.\nMy workflow:\nChange code.\nRun geth with --cpu-prof\nGenerate graph from .prof file.\nRun on cloud overnight.',
        'What are your biggest frustrations?': 'Yesterday – spent 3 hours!!! – fixing compiler errors. The codebase is large.\nAdded an extra flag to switch db to another from LevelDB. Compiling errors in fast-sync and light-client.\nCodebase has a lot of baggage: Geth has Whisper, Swarm, and light-client.\nDo geth developers want to separate these out?\nPotential concurrencies & SSD improvements.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Optimizing Geth:\nIt all started with a rough kinda experiment – in November network became congested –\nStarted doing profiling in Go. Learned to do it then.\nSaw that geth was mostly talking with LevelDB database.\nThe process:\n1) look at the profile\n2) ask questions – why is it slow?\n3) then look at code, edit, experiment to improve.\nThe system is complex – hundreds of goroutines running at the same time.\nTrying to optimize the state management. State is constantly growing. Things will have to be written on disk; fetching it again will be slow. Can have cache, but what if it’s outside of the cache.\nProblem 1) speed of processing.\nProblem 2) if you’re running a full node –\nFast-sync: download all the headers + download enough state objects from other peers to only verify randomly selected blocks.\nThen, after this, you become a full sync node.\nWhole state from beginning is ~ 600GB.\nIt needs to be compressed.\nHow do you test your optimizations:\nPeter from Geth told him: you can export the blocks, run through your node without being connected to network, and process.\nJameson Lopp:\nHis criteria for a blockchain: how quickly it syncs.\nIdea for bounties:\nShared resource: have block data sliced up into pieces (e.g. first 100k blocks, second 100k blocks etc.), give it a Github branch, spin up the image, it does a git pull, launches an instance of the client without p2p mode, imports this part of the blockchain, does comparison across different parts (e.g. when there was a spam attack in ~2.4m block)\nMy goal: to go through spam blocks really quickly. Every sync should be very fast.\nPeople complaining (e.g. exchanges) that they can’t keep up with the blockchain – e.g. Etherscan – falling behind. The clients are becoming inefficient. Instability problems. “When quantitative changes become qualitative” – breaking points are hit.\nGo-ethereum developers are also working on this – I do the same – but I like not having the responsibility and just hacking around.\nCollaborations between different clients: Parity & Geth\nParity had a great breakthrough – how to tune parameters of database – can sync on HDD. I’m hoping that collaborations will grow. State management across clients is important.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Nick Johnson\nPeter from Geth.\nQuickblocks founder – Jay Rush – quick access to blockchain data. Working on the problem of quick state download.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '90': {
        'Name': 'Simon de la Rouviere',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'Autonomous artist blueprint has existed for more than a year. Someone just needs to copy-paste and build it: https://medium.com/@simondlr/lets-summon-an-autonomous-artist-a-bot-that-creates-owns-and-sells-its-own-art-ada1afad086a\nA lot of curation market stuff: usage, governance and management of the community.\nThere are different interesting ideas around this. Dmitry from Ocean proposed a model where a bounty is funded collectively, then it graduates to an NFT after a certain threshold. Will go back to him for more details on this.\nThe usage of curved bonding for network effects on bounties: let’s say Status wants to issue a bounty. The buy Status bounty tokens on a curved bond, backed by SNT or Eth. This is valuable because, over time, if Status only uses Status bounty tokens for their bounties, you slowly build up a network effect around that token. Can either sell out or hold the tokens if you believe more people will fund more bounties in the futures. This allows people to speculate on the work being done in Status - it is a really a super-powered donation though.\nIt’s kind of like network effects for investment or VC.',
        'Who are you and what are you working on?': 'I have been in blockchain since 2013 working in BTC. I have always looked at this stuff as a tool to enable creators, so I built an app that let people sell digital goods for BTC.\nStarted building on Ethereum when it was announced in 2014, and then more actively late 2014, working in the stack.\nCurrently most time on: Ujo music - decentralized licensing platform for musicians.\n30% of time on Curation Markets - monetize new networks of value and coordinate toward shared goals.',
        'What are the tools/libraries/frameworks you use?': 'I am the smart contract lead at Ujo, so spend most of my time writing Solidity and tests.\nWriting tests in Truffle and to deploy contracts.\nGenerates helpful build file with info about deployment that can then be ported into any frontend app through a simple JSON file that can have multiple networks and contracts specified in it.\nSometimes use Remix, mainly for catching syntax errors more quickly (than Atom at least, my other IDE). Works well for quick interaction (using MetaMask) with smart contracts.\nJust truffle’s contract libraries to interact with frontend\nUse Oraclize for on-chain price oracle for Ujo stores.\nStrings library built by Nick Johnson that helps us parse strings in the registry more easily.\nWrote our own ERC-721 implementation as well.\nAfter CK came out, there was no fully standardised implementation. The community was still iterating over the standard, OZ also wrote one. There were some stylistic changes that Consensys wanted over the OZ work, so we still needed our own implementation.\nAlso just helps with my own understanding to write this stuff myself.\nCuration market specific tools?\nTrent from Ocean Protocol is pioneering the engineering approach to analysing token systems using well known tools from his trade that I don’t understand as well as he does.\nWe use a lot of different curves for curved bonding markets, and there are some curves that are more easily visualized and assessed.\nxkcd graphs makes some interesting and easy to understand stuff.',
        'What are your biggest frustrations?': 'For me, it’s always been harder to evaluate this, because I come from building on BTC, which is orders better than the dev experience there.\nIt’s always been “good enough” for me, even though it is improving rapidly all the time.\nIssues with Infura detailed above cost me quite a bit in failed deployments, and the only way I figured it out was by having direct access to the Infura team, which others obviously won’t and that is an issue.\nHow deployments work with different gasPrices - it’s not clear if you should worry about things like time outs during the process. What if you set a low price, end up waiting hours, and your internet suddenly drops? What if there is a time out on the request to an API somewhere that fails?\nI always default to a higher gasPrice when deploying to make sure it actually passes and is including.\nBetter documentation around best practices and common pitfalls here is definitely needed.\nGanache has visual interface to their test explorer. Sometimes you want something with a more visible understanding of what transpired with certain transactions. Like etherscan displaying internal transactions and well-known contract events, but with visuals.\nVisual analysis/element would really help developers understand what is happening in the network.\nWhen you have multiple contracts for a DApp, you need an up-to-date document/visual interface that shows you latest deployed contract and its methods/interfaces.Auto-generating visual tools for SC that are meant for developer aid.\nAt Ujo, we have 4 contracts, a registry, a payment handler, badges (collectibles), oracle. Gets put into JSOn file in /build, but this is not visible or particularly useful for anyone but me.\nTake some info out into separate document so the rest of the team can easily see where they are deployed and what they do at a higher level.',
        'How do you handle testing?': 'Mythril is very useful and we use it.\nWriting extensive unit tests in Truffle covers a lot of the low hanging fruit and gives you a great understanding of your contracts and how they really work.\nIt really depends on the use case: i.e. checking for over- or underflow means you sometimes need to be really careful.\nBest resources to learn about tests?\nThe EVM is notoriously bad at providing good error reports.\nRevert with reason will be really helpful for this. But there might still be edge cases where it is not certain what transpired.\nYou used to require a lot of context in order to sense what\nA lot of my knowledge comes from debugging myself and following the traces through the EVM. Sometimes you just have to vasbyt (an Afrikaans word meaning, roughly, grit your teeth and just hold on).\nSolidity is moving more towards safer defaults in general, which allows more advanced devs to take the guard rails off when we know what we are doing:\nExplicitly setting the constructor (to avoid some of the Parity hacks)\nAddition of transfer function to automatically check for failure of sends (which was previously manual).\nAfter DAO hack, I started collecting information and Smart Contract best practices repo, which is now maintained by the Consensys Diligence team.\nInfura uses a load balancer between multiple Eth clients, but these have different tx pools, so during the migration process, it is pinging infura, but it is shuffling the request to different node each time, which eventually cause the migration to fail.\nHowever, the error reporting from the client claims that the nonce is too low, which is technically true, but not at all descriptive about why the migration actually failed.',
        'What tools don’t exist at the moment?': 'One thing that comes to mind is a mature, incentivized storage platform does not really exist, still. Swarm has never really answered my immediate needs, and I worry sometimes that it is a bit too similar to something like S3.\nWouldn’t need to solve all problems immediately, just needs to be better than what we have today. Infura provides access to the IPFS network, and then backs them up themselves so that they have guaranteed access to it. Which is good enough, for now.\nIn the future, if you’re going to have 1000’s of GB of media, this will need to be looked at much more closely.\nProtocols labs multi-hashing scheme is very useful in addressing the content.',
        'Other domain specific questions?': 'What are the biggest challenges for Ethereum right now?\nIt’s still uncertain to me how the development experience will change when scalability improvements start to get deployed.\nWhether it is sharding, plasma, side channels etc, what changes from a development perspective?\nHow do we choose which shard to inject our contracts into? How does the network load balance this?\nWhat does a dev need to change for Plasma, and what does it mean for UX? Does it need a separate MetaMask, or do we need to build our own in-browser wallets again?',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Curation markets!\nMore collectible stuff. The art scene is finally catching on, which is great. The cypherfunks, which were four years too early, are being discovered again through no work of my own, which is awesome.\nI just want more people to be able to do what they want to do, more often.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Google, gitter, ETH stack exchange.\nSome Consensus resources that we all use.\nMost of Consensys’ internal stuff is moving toward being external-facing and most of his stuff should be open in the future.',
        'Are there any other questions we should be asking?': 'Curious about how we plan on dispersing the money? How do we decide on spinning up new teams to work on stuff or find existing teams working on it and enabling them.\nWouldn\'t make sense to fund multiple implementations of something? Take the block explorer: what about etherscan, alethio etc?'
    },
    '91': {
        'Name': 'Alvaro',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'VirtuePoker – offchain game, smart contracts to represent state of a poker game – offchain consensus of consensus, and submit to onchain.\nBuilding poker with Ether, that can be played without an intermediary.\nWhen you leave the table, you cash out with the stake which you have left',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Whisper\nBuilding a p2p game. We tried using Whisper for real-time communication – does not have receipts; we have discarded it right now.\nRead a Stackoverflow about Status’ problems building on top of Whisper.\nThe P2P is tough – need to be direct peers –– need to run neighbor nodes yourself.\nConnecting the mesh is tough.\nSO post said that Whisper doesn’t acknowledge receipt of messages.\nRunning whisper on a geth node is optional.\nPROBLEM: whisper has low adoption.\nAs a result, the game cannot be decentralized. All messages that are passed to each other between clients, are going through a centralized center.\nPeople use WebRTC with direct connections. But won’t work for them because they don’t want to reveal people’s IP addresses.\nThere’s also a protocol called Telehash.\nDHT.\nWeb3\nSwitching to new release soon – interface change is coming.\nCallbacks are annoying; should use promises.\nWe promisify the functions themselves.\nWe’ve only used web3.\nA web3 alternative, ether.js (from L4)\nSolidity\nWhy doesn’t it have common data structures? e.g. a simple array; if you delete one item, you get a hole in the array.\nNeed a way to store data that is indexed and where it can be safely deleted. Manually doing this stuff is bad..\nThere are many implementations of this; but having a standard implementation would be really helpful.\nA lot of these things should be built into the language.\nSafeMath. I don’t use a lot of libraries otherwise.\nEthPM? -> It worked, kinda?\nCreating more low level libraries[a]?\nI like Remix. It has improved a lot.\nI had no problem with the UI.\nLike testing in Remix – though the debugger could be improved.\nTruffle is good, as well.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '92': {
        'Name': 'Javier Franco',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'How to simplify the way to calculate the gasPrice.\nHaving an estimateGasCost when you send a transaction?\nA lot of people have trouble when sending a transaction with a low gas cost, doesn’t get accepted – but you can replay the same tx with the same nonce with higher gas price and overwrite\nWallets need to implement this, it would help a lot of people.',
        'Who are you and what are you working on?': 'VirtuePoker –– making the migration to the new problem.\nWe have a Proof-of-Concept on Python; implementing in Electron.\nTalking to Plasma, to use for scaling and also gas costs. This is a big problem.\nThe poker game actions are all done off-chain; the money stuff is on-chain. The winner reports the results. This is on-chain and expensive. Even reporting on the results costs $1.\nOffchain stuff:\nP2P network between all the peers – just a centralized API right now. Later want to be p2p without a server, but could have attack vectors with people listening in.\nBuilding the backend – regulatory process – if you lose a hand, but thought you won, you should be able to call in. Also to prevent collision. View patterns.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Gas costs:\nEthereum price increased, gas priced also increased, then CryptoKitties launched –– gas cost of $1. We think the only solution is Plasma.\nIn the beginning, it’ll be only a chain for payout. Won’t have the EVM. The first Plasma implementation won’t be a EVM – will be only for sending payments.\nWe’ll be moving from this to a payment-only architecture.\nDocumentation is very weak – Plasma especially.\nNew joiners, suffer when learning. Compared with, say, Javascript.\nEspecially since we’re all in a phase where new developers are entering.\nEthereum Foundation examples has not changed in a long time.\nThere’s no rollback when you deploy a contract.\nDeployment costs of a contract is expensive – the Dutch Auction for their ICO costs 1 ETH to deploy.\nWe were using Truffle to test. Achieved 97% code coverage.\nTestrpc. Mining a lot of blocks.\nTesting code based on temporal logic, number of blocks, e.g. you want to protect funds for 90 days or so.\nCan achieve same result with 20/30 minutes of blocks.\nThis kind of testing is really slow.',
        'How do you handle testing?': 'Testing our Dutch Auction ICO contract:\nWe were targeting 100% code coverage.\nThe contract allowed ICO to stop in two ways:\nBy hitting the market cap\nBy calling stop (?)\nThe time between the auction being finished, and the tokens being claimed, you want 7 days.\nThis is equivalent to 30k blocks.\nHow to test? You hardcode lower numbers, test (which is slow), then switch in the real numbers.\nWhat a solution for this would look like:\nThese tools could have a way to mine the number of blocks you want, instead of block-by-block.\nStress-testing the economics & game theory of ICO contract:\nTo be able to bid, you need to be whitelisted. Then, the amount you bid is also limited.\nSolidity:\nIt’s a simple language. Not very complex. Problem is you have to be very strict about testing everything; not even leaving a single line of code without coverage.\nE.g. Parity bug. All contracts where using the same contract.\nE.g. if you want to use an external function of a contract, and that person kills the contract, you are screwed. Kinda like someone deleting an NPM package you depend on. But there’s no roll back.\nWe are moving towards factory or library-driven contracts.\nWe will have a proxy contract.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '93': {
        'Name': 'Rick Dudley',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'I worked on EthPM briefly.\nI gave up in frustration\nI was working at Monax at the same time with RJ and Jan.\nThis is a good bounty that we’re going after.\nBigger problems within EthPM:\nFundamentally, in Ethereum, we have contract immutability.\nIf I take the same bytecode and deploy it to two different networks, it’s going to have different hashes. So how do I reference the code across my local, testnet, and mainnet environments? How do I reference that in my dev environment? -> the contract address won’t be the same.\nWorking on at the moment?\nVulcanizeDB with Maker as their client.\nSteps:\nTake IPFS (the content-address allows you to verify the content is correct) and retrieve the data\nSQL query – you do a search given parameters and you get back a result set.\nBecause you trust the database is free of faults.\nVulcanize: our result-sets contain content-addressable data.\nETL system for blockchains.\nPull blockchain data into a Postgres database – load all blocks, transactions, tx receipts.\nYou as an engineer write a transformation – which also generates a GraphQL endpoint.\nYour dapp can then pull that data on an ongoing basis live –– pubsub, polling, … The data is also content-addressable.\ne.g. you put the events for a contract into a table, you have a block range, a contract, in this table\nThen, you take that table, do a pg_dump, and put it into IPFS.\nYou can then verify that using your own client.\nGithub / vulcanize / vulcanize.db\nWill be released soon.\nWill eventually write a DSL for those transform.\nStandalone vulcanize db reads from one node, but can gossip the transformed to other nodes.\nInteractions with IPFS, Tendermint, Lightning, …\nFederated exchange – decentralized exchange\nOnce you have that system; then the Tendermint validators can have a system marketing\nTendermint validators can be bonded on Ethereum AND they promise to route the Bitcoin HTLCs',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Lack of people over 40 – naivete.\nTrust and guarantees – which crypto gives you which guarantees?\nThe claims of Ethereum – what features are worth preserving.\nContracts are immutable; but state is mutable –– contract code being mutable doesn’t give you any security. -> immutability.\nIs the RChain application model (not Turing complete) better than having a Turing complete VM?\nWe haven’t been super happy with ganache in particular.',
        'How do you handle testing?': 'I like the DappHub stuff; but it’s not fully integrated.\nThere isn’t a full testing suite; no way to go from the Solidity integration tests, to full-stack integration tests.\nCasey Detrio worked on testing & fuzzing within Ethereum Foundation codebases.\nBut they don’t run simulation networks on updates, so there could be consensus breaks.\nFor instance, the airline industry does this. Airlines use BFT within fly-by-wire systems.\nCheck out: videos from SQLite author explaining how they did testing.\nOur testing:\nWe use both Zeppelin and Dapphub.\nPhantom-js test of something that uses IPFS and Ethereum.\nMonax had a lot of great tools, that didn’t get the attention they deserved in the community:\nCounterintuitively, the federated context has higher security requirements. Your clients ask tougher questions than ICO token buyers.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Bottom-up sharding scheme\nAn app-sharding model.\nPut a market-based order based on parameters on what validators you want.\nActive bounty is a hybrid between a consulting contract & a bounty?\nWith Github, you have the opportunity to watch source code writing (commits) to deployment on mainnet –– the whole process cryptographically held together',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '94': {
        'Name': 'Evan Van Ness',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Have only ever played around very early, but never built anything seriously\nPersonality isn’t suited to writing bug free software, which is what you have to write in this space, and not a serious enough developer\nThe idea of writing code with actual value attached to, direct value that you can never take back in the case of an error.\nI’m glad others are developing, but I would lose too much sleep.\nI run the Week In Ethereum newsletter, and has become a full time job at Consensys.\nClose to 40hrs a week to curate\nDo a podcast as well.\nModerator of r/ethereum',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'It’s tough for everybody in this space to balance the “Wow, this will change the world” with the “Wow, this is really nascent tech”.',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Let’s talk a little about why you’re skeptical of fat protocols?\nNever met Joel Monegro - hear even he doesn’t agree with the way people interpret his article.\nSame day as his “there’s no such thing as fat protocols,” Jake Brukhman wrote Fat Protocols is Not an Investment Strategy.\nIn the very long run, this is a kind of database that will get commoditised. There will be parts that are decentralized, parts that will be centralized, public, private.  No reason to think the protocol will always be where value accrual occurs\nWhat opportunities exist or others to get involved in the community?\nTranscribing calls - core dev, plasma, sharding, etc\ndo actual UX reports and write them up well.\nMonthly and daily newsletter that are out there and could also be improved.\nPlenty of technical builders are frustrated because their projects don’t get the attention they deserve. Helping those teams with marketing is really necessary and could be bountified.\nThere are other projects have developed languages that compile to the EVM that are more safety focus and not entirely clear on open sourcing them because they are worried about maintenance.\nMore general problem of people open sourcing tools that they don’t really want to maintain - so bountifying those important projects is a possibility.\nHaving a financial reward can actually hinder people if the work is creative. Only really helps when there are pretty clear guidelines and it is more a problem with motivation.\nWhat is your general strategy to getting involved in the Ethereum community?\nAnybody can start a podcast and there are A LOT of interesting stories to tell in this space because we’re all a little weird.\nEspecially if you put a bit of effort into the editing part!\nConsiders the newsletter a “tool that helps people be more productive”.\nIt’s really interesting that there are non-coding things that can achieve this effect and figuring out others would be really great community-based work for non-technical people to do.\nSame thing for writing simplified versions of some of the technical papers and research that is being produced, a la Beige Paper\nThere are lots of different lists of info, sometimes up-to-date, sometimes not. People at Consensys have put together a list of all the developer tools, which should be opened up at some stage soon.\nA lot of this stuff is ephemeral. If you don’t see the announcements and use things within a few weeks, they can often slip off your radar.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'NexusMutual - on chain smart contract coverage - risk coverage for your solidity code. It’s very necessary for the ecosystem right now. Goal is to become a thing that is seen as as necessary as a security audit and a bug bounty program.\nScaling is getting closer! FFG is pretty exciting.\nPrediction markets are still exciting (but we all keep saying that).\nWe definitely need to keep iterating through compensation and incentivisation for working on public infrastructure, And making it such that people can open source their stuff in such a way that they don’t then forever need to spend the rest of their time maintaining.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'All the information used to be on Reddit, and there were some Skype channels for the people more deeply involved.\nPart of the reason the newsletter takes so long to curate is that news has decentralized\nUsed to joke that the newsletter is just copying links on reddit\nSpend a lot of time finding things in twitter.\nA lot of new projects don’t know that r/ethereum is the main gathering place for the community.\nDoesn’t touch on East/West divide of the community.\nI feel like I have low visibility into the Asian ecosystem.\nOne of the brilliant insights from Vitalik was to go and spend so much time in Asia to make it a global thing, but there is still a lot more work to be done on that and in connecting the communities in general.\nTranslations are always a big part of this.',
        'Are there any other questions we should be asking?': 'There are a lot of people with tools for themselves that are not well maintained.\nThere is some solution space out there where that gets solved and we need to find it.'
    },
    '95': {
        'Name': 'William Entriken',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Started using Ethereum in December.\nCreated ERC721/161 to support my project. It was contentious, I won the fork wars.\nUnderestimated how crazy this ERC721 process was.\n721 is the first standard that’s actually an Interface.\nInterfaces are broken in Solidity.\nStarted filling bugs in Solidity. –– interfaces should be able to inherit from interfaces.\nExternal vs public in interfaces. I fixed it.\nFixing things in Solidity –– basically rewriting the whole inheritance model in Solidity.\nIn 721, I had a caveat section, “errors in Solidity etc” ––\nPeople said: “the standard shouldn’t say a function is payable” –– but I said that the interface needs to enforce this.\nGot the attention of Christian, Alex, Hudson.\n721 had a dependency on 165. So I started to fix 165.\nMainly occupied with full time job, speaking re: 721 and its use cases at conferences, evangelism, million dollar homepage, navy, google, hardware (semiconductors)\nBig open-source guy, worked on KDE project, worked in semiconductors.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'The #1 problem:\nMy mom wants to buy ETH. In order to do this, she has to go to Gemini, give her SIN, give access to webcam, and access to their bank account.\nBiggest bank in this ecosystem is Coinbase.\nEvery ICO is “illegal”\nNeed a new crypto bank. This bank needs to solve two huge problems:\nIdentity management (provided by the bank themself).\nAnti money laundering\nThe #2 problem:\nSolving KYC / AML for the general population, is understandable, and secure\nCouple solutions like <$300 transactions lets you avoid AML restrictions',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Lack of private/business incentive to solve Bank/payments, not exchange, problem in crypto.\nThe ERC process:\nBring initiative, there’s forks, solve the problems –– being polite, being political, making phone calls to reach consensus.\nProblems:\nProblem #1: Ethereum is centralized. Code / governance is handled by one party.\nThis is the “EIP” process.\nThese aren’t technical reasons, they’re political reasons.\nThe EIP process:\nAnybody writes an EIP – must be technically valid, describes a change to the Ethereum ecosystem. “I want a sidechain”, “i want to change the gas for this opcode”, etc\nIf the EIP is implementable (i.e. it compiles), it’s accepted as a draft.\nIf there is community support, it’ll be reviewed by all core devs.\nIf it is supported by core devs, it is implemented.\nIf people support it, then people will upgrade the clients.\nHow it actually works:\nYou publish the EIP. There is a storm of discussion; emotional, backhanded.\nBlackballed for mentioning cultural/political taboos\nPR is not the right word for it. More like a wiki.\nThey discuss it at the core dev meeting. They implement the code, clients upgrade it.\nSomeone puts it on Hudson’s PM meeting agenda\nHow Swift (from Apple) handles this:\nYou go to the mailing lists, you start a discussion.\nThis takes a lot of effort, so you wanna be sure your stuff is legit.\nBig discussion in the community. Swift is centralized (one party). You need code already, a test case or something, you explain technically in-depth. You get it to review, 2 week review period, it’s posted on top of Apple Swift website + goes out to mailing list.\nThe key point is: the 2 week speed pump. Everyone has to pass through that.\nHow DARPA handles bounties\nHere’s a very specific problem and you need a 100x improvement\nCome up with working solution that can support network of 10k\nIf you can do it elegantly, here’s 50k and we’ll study it further before implementing\nThe community expects full-time people; they don’t cater to part-time contributors.\nA contributor needs to look at all issues and PRs –– there’s no queueing system. One could get approved at any time.\nThe ERC process:\nWrite an interface for a contract. He wrote 165 and 721.\nA ton of new token standards.\nFirst mover advantage to writing standards/interfaces - something like street cred for devs.\nOver-standardization occuring\nNot enough focus on what people would actually want/need to use\nI don’t see the need for a package manager, the existing tools seem adequate.\nNot enough money allocation from teams to bug bounties.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '96': {
        'Name': 'Christopher Goes',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Wyvern is an application agnostic protocol for exchange of transactions, not tokens\nParameterisable orders - kitties with blue eyes, discovery mechanism\nNFT, bonds, collateralized debt obligations, pools of cats, where people care more about the  parameters of the asset\nBuying and selling of smart contracts. Use case- rental of smart contracts in exchange for fees\nLike the 0x for transactions, ethereum assets\nProxy account system where users create DEX orders that execute transactions under specified conditions.\nAbstracting over Ethereum bytecode - anything you can send over eth transaction you can buy/sell\nMostly written in January 2018',
        'What are the tools/libraries/frameworks you use?': 'Solidity, Typescript, Truffle for deployment, JS front end\nBytecode checking handled by libraries\nBytecode of your order (constructed in UI) is checked vs orderbook\nHow are you building the front-end to construct bytecode?\nhttps://exchange.projectwyvern.com/\nWyvern schemas library maps bytecode to visual representations',
        'What are your biggest frustrations?': 'Solidity - I find it difficult to write complex, high-assurance code vs Rust/Ocaml etc.\nWyvern uses large exchange core contract\nSystem of several contracts (delegate calls) needed to validate order\nI wish there were easier ways to use typescript rather than javascript with solidity. Calls to the contract (from javascript) are mostly untyped. I definitely want better statically typed testing tools that are clear and easy to use.',
        'How do you handle testing?': 'Oyente\nSolCoverage is super useful\nJavascript tests\nCurrent experience writing tests in solidity is terrible. Could be better with a better interpreter.\nCurrent static analysis tools focused too heavily on reentry bugs, post-DAO\nSecurity audit on Wyvern revealed that a non-zero contract balance tool\nMore edge cases needed between Solidity and EVM gotchas',
        'What tools don’t exist at the moment?': 'Local, easy Solidity interpreter\nCurrently, tests are done on EVM through a blockchain\nMost things you’re testing don’t rely on blockchain features (timestamps, block # etc.)\nEasy interpreter that runs locally on computer not through ganache\nAlso, Better gas measurement- line by line gas cost analysis\nHis workaround was using solidity assembly code (well documented)\nUser account experience would be better if people used contracts instead of standard accounts\nWyvern already uses user-owned smart contracts as their user account\nInstead of ERC-721 way (smart contract approved to spend your funds). If users had proxy accounts, they could create global limits on spending of tokens. Wouldn’t need to track approvals via various individual contracts.\nCustom rules for fraud detection/reversal could be set up (i.e. double confirmation/ time period required for transactions > $xxxxx)',
        'Other domain specific questions?': 'What are the barriers to Wyvern usability (by relayers) and liquidity?\nWyvern is an exchange contract, not a platform\nPlatforms will diverge in their purpose\nOpenseas could use Wyvern\nEconomic model set up which they could take fees. Can be used by relayers to take fees in Wyvern orders\nWould more expect relayers in different verticals, more\nWyvern makes it easier to share liquidity (between relayers)',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Introduction to Ethereum Medium post: https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369\nEVM yellow paper, Solidity documentation\nEdge cases can be super technical - go look at the hardcore docs if you really want to know. There are no easy answers for some things, after all.',
        'Are there any other questions we should be asking?': null
    },
    '97': {
        'Name': 'Matt Condon',
        'How do you handle smart contract verification and security?': 'Nothing, no real process besides following best practices.\nGets auditing. Should be running Mythril but hasn’t set it up yet. They have a great blogpost on finding unchecked self-destruct.',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Built a raffle contract, but didn’t ship it because I didn’t want to deal with real money in early 2017\nFirst thing I shipped was steak.network\nNow building XLNT and gnarly\nSolidity contracts.\nOff-chain clients.\nFrontend interfaces for blockchain-backed stuff.',
        'What are the tools/libraries/frameworks you use?': 'Truffle, Infura, MetaMask, Etherscan, Remix, Solidity flattener.\nIf not already mentioned, are there any libraries you rely on regularly?\nWeb3, BigNum, moment, Numeral, Chai, Mocha',
        'What are your biggest frustrations?': 'Iteration cycle is slow, especially compared to webdev\nNo visibility into errors in solidity. No error logging, no line numbers. Complete black box.\nPeople end up commenting out lines, deploying testing, re-editing just to figure out bugs.\nNeeds to be fixed at the EVM level.\nLogging is undefined. don’t really know how you’re supposed to log even though I have read all the docs.\nThe solidity inheritance interfaces are weird. Really likes Bamboo for this reason.\nGanache fixed a lot of testrpc issues. But it doesn’t support websockets so that’s annoying. But at least you can actually use geth in dev mode now.\nAre you running into problems with any of the following:\nGas limit: Yes, in general.\nOff-chain computation: Yes, open problem for TrueBit. There’s gotta be some best practices for setting up state machines and stuff like this.\nState Channels: Haven’t used them.',
        'How do you handle testing?': 'Try not use truffle test.\nNever written a solidity test, but written a lot of JS tests.\nAlso do some manual integration tests using Remix to deploy to Ganache or something. Using remix for this testing.',
        'What tools don’t exist at the moment?': 'Truffle has a lot of rough edges (documented elsewhere)\nGas profiling\nInteractive debugger that works',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Mental model of how blockchains work. Also mental model of how Ethereum works.\nI wrote an article called “Getting up to Speed on Ethereum” that answers the vast majority of question I had when starting.\nTokens are just numbers in a database with an API to add and subtract. Not some native object or something.\nSolidity the language, besides its quirks, is not hard to learn. The hard part is understanding the environment it’s executed in, and what that means for your program\nWhat would be the hardest part of teaching a software engineer to build a dapp?\n“Solidity is just like javascript” - THIS IS SO LOADED WITH WRONG IMPLICATIONS\nPeople’s understanding of web development doesn’t really transfer\nSoftware engineering principles transfer, but it’s not just web development.',
        'What are you most excited about in the short term?': 'Biggest hype tech is token-curated registries. Curate a set of things such that the resulting registry is more valuable than the sum of its parts. Use that to create economic incentives around rational behavior for the curation process.\nE.g.: machine learning if you want to create public images for a dataset\nE.g. structure government as a token curated registry where laws are curated into a constitution. If someone thinks their expertise will increase the value of the constitution they can become a curator\nMostly interested in 2nd layer projects that don’t exist for crypto’s sake',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': 'All of the people in Cape Town that I just met.'
    },
    '98': {
        'Name': 'Ramon Recuero',
        'How do you handle smart contract verification and security?': 'Found a list of the top 10 security vulnerabilities; reentrancy, math overflow, ...\nYou don’t know what you don’t know.\nHow to find info:\nGoogle / reading about the DAO hack / Reddit.',
        'Other bounties?': 'Having difficulty in hiring people – most engineers don’t understand blockchain.\nDon’t have much to show for it right now.\nSoV\nInfrastructure needs to get exist first.\nLack of use-case, to be honest.\nExplaining the data model for blockchains:\nE.g. similar to: Dan Abramov: Redux devtools on the right.\nMaking an interactive demo of data flowing through.',
        'Who are you and what are you working on?': 'Last summer, developed Redis on Ethereum. Simple to read & write data.',
        'What are the tools/libraries/frameworks you use?': null,
        'What are your biggest frustrations?': 'Was pleasantly surprised with Truffle - testing was easier than expected.\nWhat was hard:\nDebugging. Solidity compiler error messages could be better.\nThere’s no console.log, can click and step into the code.\nGoogle and Stack Overflow are often the best resources when running into bugs.\nTrial & error, until you get through it.\nIt’s difficult to communicate this to other people.\nGetting the mindset for developing for the blockchain is hard.\nHard to remember,even harder to explain to other people.\nDeploying to testnets and mainnets was hard.\nHad trouble with gas.\nGetting Ether on the testnet. No faucet.\nFound developer on Reddit Ethereum thread.\nNo chance to update the contract. Just pushed new contracts.\nEth npm in the beginning.\nDifferent ES6 configurations in front and backend',
        'How do you handle testing?': 'Redis had the smart contract. Made an npm library; had Truffle tests + npm tests.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': 'Testing in Truffle.\nIs simple if you come from the Javascript world.\nMetamask.',
        'Who are the other people you think we should talk to?': 'Blockchain Berkeley Lab – professor – working with students learning blockchains.',
        'What are the best educational resources?': 'Did Coursera course to implement blockchain, but it’s likely not the best.',
        'Are there any other questions we should be asking?': 'Share your learnings, get the community back in, and do another iteration.'
    },
    '99': {
        'Name': 'Facu Spagnuolo',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': 'For governance:\nWe are still exploring which models are better for upgradeability. How to take into account the community, dev team, investors etc. We need a governance pattern that works specifically for upgradeability decisions, which tend to be more focussed than larger governance questions and might lend themselves to specific, narrow mechanisms.\nIt may be possible to modify the way the compiler maps state variable to storage, so that we can allow people to implement similar patterns to ours without all the inline assembly stuff. Might make a nice bounty - improving the compiler in general to allow new features specifically in terms of what you can do with the EVM.\nHaving a scheduler implies huge gas costs, so we need to find scheduling mechanisms that will allow the community to run transactions in a feature for you and be rewarded with tokens or Eth or whatever. (see chronologic for this kind of stuff too)\nWe are trying to see if there is anyway to use TCRs and token curation markets in order to handle on chain standard libraries and upgradeability too. The idea behind zeppelin OS is to encourage other teams to build their own on chain standard libraries and provide them through zeppelin OS to be used in other projects. We would love to see the community come forward with suggestions about how this could be best managed.',
        'Who are you and what are you working on?': 'I studied Computer Engineering and am a full stack dev. I started my career by programming web stuff and distributed systems.\nA year ago I had heard a lot about BTC and “blockchain”, so I got involved.\nMy life goal is to build the technologies that will make people’s lives easier and more free.\nCryptocurrencies clearly can do this, but Ethereum specifically - because of the community, and the fully functional VM on a chain - is clearly the best platform we have so far.\nI knew Manuel from before, and so got together with him and decided to start building some tutorials and interaction guides to walk people through the same forests I was exploring. Started contributing to Zeppelin as a security researcher, because that is the major focus at the company.\nThis gave a lot of background as I really had to grasp how thing happen in the EVM. You have to be incredibly conscious and attentive about the stuff you’re programming.\nAuditing well-known projects also really helped me grow my knowledge of how the whole ecosystems works and what the best practices are.\nI am now building Zeppelin OS - upgradable smart contracts, with a scheduler, and on chain standard libraries.\nIt’s a huge challenge to build this on Ethereum currently, so I became a core member and we are releasing our first version today!!',
        'What are the tools/libraries/frameworks you use?': 'Truffle - I don’t really like it, but have to use it.\nWe can improve a lot of things here and build some more things on top of it.\nTesting your contracts easily across any network and setting your own defaults through the console is not as easy as it should be.\nTruffle scripts allow you to deploy your application, but the truffle environment itself is very difficult to manage, especially if you need to modify it to fit your specific project. You can lose days trying to do that.\nWe should start thinking about providing an interface that can be consumed, extended and used by other cmd line tools, and things like zeppelin_OS.\nThe testing environment is really good, but could still provide some extra features (like better debugging and changing variable easily between tests without needing to recompile everything).\nI haven’t yet found one chance to run the debugger properly - but we really need that and it really needs to be easy to use.\nWhen I try to debug my contracts on the network, I start logging events on the smart contract to see what is happening. This is really slow, it is a waste of gas and is not the way I want to handle things in the future.\nWe also use open zeppelin a lot in our own projects: i.e. DApps we build ourselves, and zeppelin_OS - an on chain version that can be used as a standard library for zeppelin OS.\nCurrently you have to deploy manually the smart contracts from our libraries that you want to use. But now, with zeppelin_OS, everyone can build a standard library that can be linked to a project that is using zeppelin_OS and everyone can use the same source code.\nSay goodbye to all those deploy-time issues ;)\nWe use many small helper libraries: e.g. to do tricky things like testing low level calls, crafted transactions where you need to specify very small things to do with the data as an array of byte or whatever. Truffle provides no friendly way to do this, so you have to start playing with buffers of bytes and hashes and all sorts of nonsense.\nEthereumjs-abi, ethereumjs-utils etc.\nWeb3 is a great library. It’s very simple, though it’s been a long time that they have been promising a stable 1.0 version.\nMetaMask is also really useful - makes life easier in so many ways.\nWe use both geth and parity as we have our own nodes to test things.\nRemix is really cool and it works really well. I encourage people to use it and look forward to new releases from them.\nSharing sets/suites of contracts easily can be improved.',
        'What are your biggest frustrations?': 'Speed of testing in Truffle is taking ~15min and it should be 1-2 at most. We need to speed that cycle up badly.\nRopsten is really slow when we need to test something in a “real” network. We have needed to cancel manually our own transactions and follow many rabbits down many different holes to figure out what happened. We need a better, more realistic testnet, for all our contracts.\nYou can’t set breakpoints when debugging contracts, or end-to-end transactions on the network and this can cause you to lose the whole day when you miss something as simple as a flag or a param in a contract etc.\nNo easy way to log things in Solidity, which makes missing the stuff above much easier than it should be.\nThe linter tools also take too long. It should just be possible to install and run these sorts of things without needing to do any config of your own, which is not currently the case.\nSolcoverage has to be set up manually, and the docs kind of suck around this. It took us a long time to figure it all out for ourselves.\nPlain solidity console/interpreter to test your contracts where you can play with the types, variables and scopes without needing to recompile everything.\nVolatility of the markets - really hard to convince people to join and use the currency because of this.\nLegal issues around launching companies and products are a real PITA. We need proper DAOs and soon.\nCame out of web dev industry, and it is really mature. They have a lot of methodologies for running projects and organising teams. Most people in Ethereum are very young and these sort of processes are generally a mess.\nThere’s a lot of pressure on the back of the price, and this or that ICO and we need to make sure that the community supports and contributes to better, clearer, slower processes that actually achieve the desired goals rather than cutting corners to ship not-really-decentralized products.\nWe need to figure out some new processes too unique to the problems we face in crypto.',
        'How do you handle testing?': 'We use Travis CI.\nCoverall for coverage tests, also for solidity coverage using solcoverage as a plugin. Super useful to us.\nWrite plain mocha tests (integration and unit) and we aim for 100% coverage always.\nWhen working on DApps we usually have standard paths to test how the UI works.\nThis is another developer tool that is missing: a tool to test UIs when signing transactions.',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': 'Upgradable smart contracts?\nWe’ve been exploring many different approaches over the last year, all of them using proxies: i.e a contract using a delegateCall opcode to make things happen.\nBiggest problem: we had to store information about 2 different domains, 1 of them being the proxy information and the other the contract that needs to be upgraded.\nProxy information: delegates each call to implementation contract. Storage in proxy contract, logic elsewhere, so not something new (Parity also uses this pattern).\nWe don’t see how upgradability works without some kind of mechanism for governance: the proxy needs to ask someone/something if the contract can/should be upgraded. This information needs to be stored as well: the “owner” and the implementation details.\nThe way solidity manages storage, the contract that was going to be upgraded needed to follow the storage slots where the proxy was saving the relevant information because it is important not to overwrite them.\nWe found a final approach that manages this very elegantly: using inline assembly to store variable and bypass the way solidity performs its own checks. We are using storage slots that solidity will never be able to access, which is how we can ensure our approaches are really safe and that we can have upgradeable smart contracts that don’t overwrite important information.\nWhy should we even have upgradeable though, if immutability is such a big thing?\nWe really don’t think upgradeability works without governance.\nWe have storage in one place and logic in another. So the storage actually remains immutable and will never forget what is put into it. We can modify it, but that is part of the history and you can inspect those modifications easily if you like.\nWe are not leaving immutability then, just handling it in a smarter way.\nThe idea came from exploring the strategy Solidity itself uses for mapping of variables, but with some delta to make sure Solidity won’t overwrite things.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Zeppelin OS!!\nReally excited to see a lot of projects on mainnet.\nDecentraland, Aragon and Status are the most exciting.\nInterested by Cardano: they have a really different way of writing smart contracts on a  blockchain and we can learn a lot from them. They also have a really good team, which is always a good lense for me to assess projects through.\nNeo is another interesting project. Haven’t used it yet, but met them at a conference and they were really focussed and clear about what they are going to be doing over the next little while.\nCosmos is really interesting! It’s really huge, but I am excited to see what happens there.\nPlasma, eWASM, state channels - all these things are going to be exciting to explore more.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Fran Giordano from Zeppelin - knows a lot about the EVM especially.\nAlejo Salles from Zeppelin - worked with quantum physics, neuroscience and AI. Mind-blowing.',
        'What are the best educational resources?': 'People in zeppelin are the best resources I have!\nOne of the things I love most about Ethereum in general is the community, so we try to get to know as many other projects as we can and collaborate with them. This is a great way of finding quick answers to hard questions and getting an overview of the best current tools available.\nGoogle, ethereum stack exchange too. But the community is the best resource we have.',
        'Are there any other questions we should be asking?': 'I would love to know how people got involved and how they managed to be where they are right now: i.e. what path did they walk to get to where they are now.\nI would really like to know if we are all doing the same things to get to where we are, or if there are smarter ways to grow quickly without losing culture/vision. Sometimes it feels like we’re all alone in the jungle, struggling to survive, and it would be awesome if not everyone had to feel this way going forward.\nWould also be helpful to see how other companies are organising themselves on a day-to-day basis and how they collaborate with other teams, with remote workers etc.'
    },
    '100': {
        'Name': 'Manuel Araoz',
        'How do you handle smart contract verification and security?': 'We design first then develop.\nSometimes they see other teams mix these two phases.\nThis is bad, because you can break your assumptions in nuanced ways..',
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Open Zeppelin: open source smart contract framework\nCurrently working on building web app\nOn chain libraries with upgradability\nContract interaction\nMarketplace\nScheduler for asynchronous execution.',
        'What are the tools/libraries/frameworks you use?': 'Use the truffle toolkit the entire way. Truffle for testing.\nPublish on npm for users to use open zeppelin.\nOne of the first to try ethpm.\nIt was super buggy with IPFS errors and it couldn’t find the resources and stuff',
        'What are your biggest frustrations?': null,
        'How do you handle testing?': 'Truffle automated testing with javascript unit tests\nMigrated to async/await style of tests\nMocha, Chai\nOnchain bug bounties for finding implementation bugs.',
        'What tools don’t exist at the moment?': 'Upgradability\nWe’re going to build an upgradable library, for the most used kinds of contracts. So that you can just use the library and it will be an upgradable form[a].\nUpgradability requires governance mechanisms though, and these are more difficult to figure out, as it is not just about code.\nWe are not working on debugging, but would love to see someone solve it\nWe use the truffle debugger but it’s not covering all their needs\nRemix is good, but we would rather not use the web UI.\nBetter tools for deploying and managing contracts on the blockchain\nWe’re building this (John & Marcus)\nTools to replay past transactions\nE.g. for historical testing of upgrades.. replaying transactions from previous versions and making sure they don’t break.\nStress-testing cryptoeconomic system: we only really do human analysis now.\nBetter tools – like simulations of the mechanism design to prevent game theoretic problems – would be cool. This can be a bounty[b].',
        'Other domain specific questions?': 'Interesting: Solidity compiler team runs OpenZeppelin tests when they update & other projects tests to make sure they’re not breaking.',
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': null,
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Jorge from Aragon.\nKevin Owocki from Gitcoin.\nOther Zeppelin devs: he will make intro.\nEsteban from Decentraland.',
        'What are the best educational resources?': null,
        'Are there any other questions we should be asking?': null
    },
    '101': {
        'Name': 'Brendan Chou',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'On chain derivatives for erc-20 tokens\nOpen sourcing their code in next week or two\nOnly smart contracts protocol so far, no UX/Dapps',
        'What are the tools/libraries/frameworks you use?': 'Remix for smart contracts\nWriting Javascript tests\nTruffle for compiling and test, NPM to manage packages,\nSolCoverage',
        'What are your biggest frustrations?': 'Running tests in Truffle doesn’t show you why/where it reverted\nMust search through binary instead\nTIME uncertainty (for interest rates). Given that time is discrete on chain, it’s hard to determine the interest rate at a given block, and it gets even harder when you think about how to do that in as decentralised and trustless a way as possible.\nNot being able to run untrusted code. If a borrower goes to repay a lender, it would be nice if that borrower could call a function to notify the lender to run arbitrary code in a safe way - maybe an obscure design pattern though.\nSending ERC token allowances are annoying.\nChanging token standards is difficult but may be necessary (see ERC 233 and 277)\nCreators and owners currently have control over smart contracts, not truly decentralized\n>0 less efficient  than !== 0 due to Solidity handling of ints. These kind of edge cases in general are difficult to learn about and it is only really by writing contract yourself and testing them endlessly that you discover stuff like this.\nDoing floating point arithmetic on chain, using Euler’s number, e, and other fun things (30,000 gas, not too expensive which is awesome).',
        'How do you handle testing?': 'Mocha, js unit tests on Truffle',
        'What tools don’t exist at the moment?': null,
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'Anything that helps us iterate faster. Tests currently take ~20 min. Currently doesn’t run more than one ethereum node per computer. Could be cool to split up tests on different ethereum nodes.\nIf you modify contract that inherits from another, you have to tell truffle. End up recompiling often.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Solidity readthedocs, stack overflow, google searches etc.',
        'Are there any other questions we should be asking?': null
    },
    '102': {
        'Name': 'Lane Rettig',
        'How do you handle smart contract verification and security?': null,
        'Other bounties?': null,
        'Who are you and what are you working on?': 'Core developer for EWASM, but independent and works on a grant.\nDoing a lot of governance-related stuff lately, EIP0, Fellowship of Ethereum Magicians\nRuns a blockchain community and coworking space in NY called Crypto NYC (www.cryptonyc.org)\nNew project called Odin Protocol, an open data marketplace',
        'What are the tools/libraries/frameworks you use?': 'Use vim, tmux and work way down in the protocols - no web3 etc.\nLots and lots of helpful vim plugins: various language syntax plugins, version control, etc.\nWriting web assembly itself (tests), Javascript and some C++: evm2wasm transpiler that can maintain backwards compatibility.',
        'What are your biggest frustrations?': 'Testing - “is a nightmare.” The way it is done at the core level is very overcomplicated and confusing.\n3 types of tests and completely separate tooling for each\nState - honestly don’t know, even after several months\nVM - lowest level, see what effect a tx has. Not documented well\nBlockchain - wait for blocks to be mined and stuff to happen.\nHistorically made sense to do this. Each client has to pass all three types of tests so that we don’t end up with consensus bugs.\nDocumentation is non-existent and tooling sucks.\nWould be great if there were a single command to run all the tests.\nHow do I run a single (VM) test easily? Or even just an arbitrary subset of tests? We use CI tools to run them instead (Travis, but are transitioning to Circle). It’s all dockerized, so getting tests to run locally is very difficult.\nThere is a tool called testeth, built in cpp-ethereum.\nTest tooling should be in its own repo! Not maintained very well either.\nIn order to run testeth, I have to download and compile cpp-ethereum.\nWorth having CI as its own separate point as it is the other biggest headache, along with testing.\nCommunication tools in the EWASM team - use gitter currently. No threading, images etc, basic stuff that is missing.\nEF uses Discord internally and there is an #ewasm channel there, but we have team members who are not part of the Ethereum Foundation and are not on Discord so we need another channel.\nSetting up bridges is a possible solution that seems to be working quite well for other teams.\nTesteth is a great place for bounties and should NOT BE A PART of cpp-ethereum\nGetting testnets up and running - there should be a test network in a box that we can just deploy at the press of the button It should not require a  devops engineer to handle this kind of stuff.\nThere is a half-baked interpreter for WASM in Go and C++, but we need one in python so that we can plug into Trinity (the new Python full node implementation that is being written from scratch and is the vehicle for research including sharding).',
        'How do you handle testing?': null,
        'What tools don’t exist at the moment?': 'Working on evm2wasm in JS - we need to be able to run all the tests using the new WASM infrastructure. I want something like a CI on my local machine, make a change, save the file and see whether the tests are passing or failing. Hot reloading for the whole test suite kind of thing. Local test harness that just works.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': null,
        'What are you most excited about in the short term?': 'WASM allows people to write contracts in non-EVM specific languages: C++, Rust, typescript etc.\nBring on an order of magnitude increase in the number of devs.\nWorking so closely on Aragon because of the work being done by everyone on governance\nFOAM is going to open up the whole world if it works as they say it will.\nTruebit is amazing.\nTCRs',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': null,
        'What are the best educational resources?': 'Solidity tutorials on ethereum.org was the place I began. Needs to be updated and Hudson is working on that. It should be the definitive source in the sense that it’s the first place people studying Ethereum often land.\nHas to be about pair programming for me when it comes to core dev. There is no documentation and it lives inside the heads of core developers. There is a repo for WASM stuff, but it is a moving target.',
        'Are there any other questions we should be asking?': 'Product management mindset is incredibly important. Ethereum full node software is quite clunky and is not user friendly. Would love to see projects further down the stack actually adopt this kind of mindset.\nDo you know who your users are? What sort of feedback loops do you have with them? How do you talk with them? Have you done user needs analysis?\nCommunication tools are interesting to dive deeper into - both internal and external.\nGovernance and signals is very important to me - how do you get a sense for community consensus? Build things that reflect the collective will of the community, but we don’t have access to that. What signals would you like to be able to get from your community and how?\nConcept in medicine called “practicing at the top of your degree” - doctors should not be scheduling or handling payments. Devs shouldn’t be worried about devops, finances, scheduling.\nWhat % of your time today are you spending practicing at the top of your degree/qualification? Talk about processes especially.'
    },
    '103': {
        'Name': 'Kames',
        'How do you handle smart contract verification and security?': 'The mainnet launch was very minimal. Using segregated accounts in uPort app, use proxy contracts that have been around like a year. These went through formal verification a while ago. We were confident with putting them on mainnet. Switching up in the future how we handle it.\nHad them audited by Consensys internally, possibly by the diligence group.\nGetting away from smart contracts, looking at a different identity protocol layer. If uPort was continuing in smart contracts  upgradeability via smart contracts (ZeppelinOS) would be interesting.\nDeprecating our smart contracts, but using ether-did (decentralization identity). Just need a private key and a public key, so don’t need a smart contract. Etherdid registry is a smart contract, but smart contracts are not the core protocol any more.',
        'Other bounties?': 'Education platform that is not focused on a business model. Loom is doing a fantastic job of educating people, but it’s a business. A great general education source that is not leading to some business. Online university or online education center would be fantastic.\nBetter UI/UX, thinking about this next layer. Get product people, designers, etc. involved. A Material design for dApps.',
        'Who are you and what are you working on?': 'I am working on uPort as a community a manager. The primary role is basically discovering how to empower developers to use uPort. uPort is a decentralized identity system.\n Getting developers to understand how to implement this in the front-end environment, get people that are not used to Ethereum to understand this\nAsk the right questions to get people thinking about this',
        'What are the tools/libraries/frameworks you use?': 'Eth.js, we use Nick Dodson’s stuff. Inject web3js, but use more of the lightweight stuff for internal requirements. We use Truffle for tests. For the Buidlbox project, we use React-Redux. Mobile app is all react-native. Use React/redux everywhere, React sagas.\nUse IPFS, use Infura. New spec puts us on IPFS, before we were just on Ethereum but this cost too much. Introduced IPFS to help with this, but it’s a bottleneck point.',
        'What are your biggest frustrations?': 'Personally, I don’t have that many frustrations. However, Solidity has a lot of updates every time and has a lot of breaking changes. It’s difficult to manage this. EthPM will help this.\nAs a team, working distributed on a lot of systems that are new is pretty tough. But have a pretty knowledgeable team.\nStill deal a lot with the JavaScript ecosystem. Heard web3js was garbage, not having promises and heard it wasn’t great. Heard Ethers.js was good, supported by Richard Moore of the Ethereum Foundation. Would be great to have education that there are other options out there beyond the most popular projects\nEth.js from Nick Dodson is super bare bones and super modular, Ethers.js is a bit more built out by Richard Moore.\nI dibble dabble in smart contracts, I do a few demos with things like token staking for events. But I am mainly in the web 2 stuff. Not necessarily building out infrastructure or production ready contracts, more of showing the general web3 flow.\nWould recommend to redo Remix, want to share code from Remix. From Remix, be able to push GitHub. More of a collaborative Remix, better UI.',
        'How do you handle testing?': 'We run a lot of unit tests on the JavaScript, but don’t do enough testing right now. For smart contracts, reach out internally at Consensys. But not baked out process. Could use a better audit process.\nCould use a better audit tool. Can test smart contracts at a code level, formal verification but haven’t researched this.',
        'What tools don’t exist at the moment?': 'Drag and drop website builder for dApps, I’m working on this. Product people are not able to prototype the user experience is very detrimental to the long term growth of the ecosystem\nNeed tools that enable quick validation in the real world. Need better prototyping\nDesign systems, design patterns, how to handle long transaction times. New thinking in this regard.',
        'Other domain specific questions?': null,
        'What was the hardest part about learning to develop with Ethereum?': 'Wrapping the head around everything in the ecosystem. Because Consensys is such a big force it’s easy to focus only on Consensys spokes, but there are a lot of other solutions out there. Yesterday someone posted an alternative to Truffle but hadn’t seen that before. Having a clear understanding of people in the ecosystem.\nA library of all smart contracts, background of these smart contracts along with user stories. A better understanding of existing tools. Search and get 5 different options for events smart contracts, or a decentralized exchange. See instantly these.',
        'What are you most excited about in the short term?': 'The overwhelming amount of events. ETHGlobal is doing a great job with hackathons worldwide, short term and long term benefit. More and more outreach and pulling more and more people in.',
        'Was anything easier than expected?': null,
        'Who are the other people you think we should talk to?': 'Linnia, they are doing market dataplaces for your data. Figuring out how they can build this out in Ethereum.',
        'What are the best educational resources?': 'Loom’s CryptoZombies and their general onboarding process, this is very approachable with good design and good practices. They’ve taken a big focus on not just focusing on the code but focusing on the experience. Not good to throw encyclopedias at people. Truffle sits in the middle, they have good docs. Ethereum itself is pretty difficult to parse their docs.\nDesigning for intermediate JavaScript developers could be very interesting. Catering this education experience better.\nJust looked at smart contracts long enough, wasn’t super intimidating as they are designed to be simple. Looking at Zeppelin, looking at best practices, understanding this stuff. But now want to get more into bytecode stuff.\nLack lower level knowledge of how to super optimize a smart contract. Want more code to look at to get at optimizing bytecode.\nuPort will be focusing on education, more videos to help these intermediate programmers.',
        'Are there any other questions we should be asking?': null
    }
}

const Questions = [
    { id: 1, text: 'How do you handle smart contract verification and security?' },
    { id: 2, text: 'Other bounties?' },
    { id: 3, text: 'Who are you and what are you working on?' },
    { id: 4, text: 'What are the tools/libraries/frameworks you use?' },
    { id: 5, text: 'What are your biggest frustrations?' },
    { id: 6, text: 'How do you handle testing?' },
    { id: 7, text: 'What tools don’t exist at the moment?' },
    { id: 8, text: 'Other domain specific questions?' },
    { id: 9, text: 'What was the hardest part about learning to develop with Ethereum?' },
    { id: 10, text: 'What are you most excited about in the short term?' },
    { id: 11, text: 'Was anything easier than expected?' },
    { id: 12, text: 'Who are the other people you think we should talk to?' },
    { id: 13, text: 'What are the best educational resources?' },
    { id: 14, text: 'Are there any other questions we should be asking?' }
]

module.exports = {
    InterviewsData,
    Questions
}