0x - Decentralized exchange protocol. It is a set of smart contracts that handle standard transactions in an order format.
The key advantage here is that these smart contracts leads to shared liquidity
We also achieve increased security and network liquidity through our architecture.
We launched the network in August 2017.
It 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.
V1 only allows humans to create orders; V2 will allow new smart contract to create orders. This is HUGE.
Notes:
We’re building the protocol; designing the standard; building dev tools for anyone to build a decentralized exchange.
Orders may become invalid for any reason:
Order being filled
Griefing attacks
We’ve now built an OrderWatcher that keeps relayers updated on the state of orders.
We’re using contract Events as a proxy for state changes.
Can do a diff between state trees and between block headers.
We also have a set of smart contracts to handle settlement;
Everyone who wants to trade is setting allowances on a smart contract.
We want upgradability.
", "keywords": [ "gas", "protocol", "transaction", "event", "network", "orderwatcher", "design", "smart_contract", "decentralized_exchange", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "EthereumJS / truffle hardwallet provider / Typedoc (to generate documentation) /
We don’t use Truffle anymore
Not reliable – can have race conditions;
Artifacts don’t allow you to have versions of the contract on different networks
You don’t run into this stuff if you’re just building a “hello world”
Overwriting parts of the contracts;
We rolled our own. It’s open-source but not documented. We have other things that are keeping us busy.
The problem is that Truffle has too much functionality –– we would like to see more of a Unix philosophy.
Cannot support different versions of Solidity.
Version management doesn’t exist.
EthPM –– doesn’t have versioning either? It’s going through a big refactor, so we held off. We need the NPM package manager.
We have built a lot of developer tools to interface with the smart contracts ourselves.
We have also built own deployer and migration tool, as truffle’s did not suit our needs.
", "keywords": [ "typedoc", "ethereumj", "solidity", "documentation", "versioning", "ethpm", "open_source", "truffle", "smart_contract", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "Testrpc has gotten better ––
Increases the speed at which you can dev.
Blockstream is really cool. Written by Mica (from Augur?), under the EthereumJS lib.
Good dealing with block re-orgs and changes in state.
Continuous Integration:
Doesn’t really work for smart contracts.
We just use testrpc.
Neufund was different than 0x:
Neufund was a trustee for tokens –– it was centralized by definition.
This made it simpler: I could create “open-ended” contracts –– a switch statement, that the default would send to another proxy contract.
But 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.
", "keywords": [ "signature", "ethereumjs", "governance", "testrpc", "issue", "augur", "security", "integration", "neufund", "token", "smart_contract", "open", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Code audits before deployment
Want to add a formal verification tool to our deployment tool.
By analyzing the code, you can find patterns.
I manually did an audit in v0 of 0x:
Make sure all functions have a “Read -> Write -> External Call” pattern, so you don’t have any race conditions.
", "keywords": [ "deployment", "audit", "formal_verification" ] }, "bounties": { "question": "Other bounties?", "answer": "Rest of the bounties from Remco
State-watching –– built-in diff’ing of state trees
Should be implemented in the Ethereum clients – Geth and Rust.
They want this feature for OrderWatcher.
EIP process is suboptimal:
Lacks in consensus-building. There’s vocal people who don’t have good ideas; there’s a lot of noise.
To improve: committee-based approach (reputable stakeholders from reputable projects who get together?).
Problems are getting solved at the wrong abstraction level.
E.g. NFT standards.
Neufund was largest Solidity project before –– tokenized equity.
You want a EuroToken. You don’t want your company valuated in Ether.
What if blockchain forks; which token is actually tied to the company?
Bounty approach gives many different styles within the codebase.
This is a problem; e.g. OpenSSL codebase after Masters / PhDs.
", "keywords": [ "eip", "vocal", "consensus", "orderwatcher", "client", "bounty", "solidity", "nft", "ethereum", "openssl", "neufund", "token", "blockchain", "rest", "geth", "eurotoken" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "1": { "name": "Leo Logvinov", "who_what": { "question": "Who are you and what are you working on?", "answer": "Started in blockchain 2 years ago in Berlin, working on Ethereum devtools, building solidity plugin for IntelliJ, built by him and an Australian.
Working on truffle, did some PRs, improving speed, usability, error handling.
Started working on 0x, primary role: devtools team.
", "keywords": [ "error", "ethereum", "intellij", "truffle", "blockchain", "usability" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "There is a limit on local variable numbers (have a limit of 16, which influences how you write the code).
Solidity 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.
ABIv2 - 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.
C++ devs needed
", "keywords": [ "limit", "compiler", "solidity", "audit" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Prettier type plugin for solidity. I don’t have time to write it but Prettier has a good API.
", "keywords": [ "type", "pretty", "solidity", "api" ] } }, "2": { "name": "Axel Ericsson", "who_what": { "question": "Who are you and what are you working on?", "answer": "I have built 1Protocol
It lets smart contracts sign up as miners on different proof of stake protocols
Let users provide the contract with the stake
It’s like a mining pool, but for staking
Three things
Interface for signing signatures (like MEW) and sending tokens to mediators
Building actual contracts that accept tokens and are signed up in Raiden as a mediator
Actually running the mediating machine on Raiden.
Eventually, anyone can send tokens and anyone can run the machine
For 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.
", "keywords": [ "signature", "protocol", "api", "proof_stake", "client", "mew", "token", "raiden", "smart_contract", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Just web3JS and the python raiden client
", "keywords": [ "raiden", "client" ] }, "testing": { "question": "How do you handle testing?", "answer": "Truffle suite. Before that, built our own unit testing system.
", "keywords": [ "truffle", "unit_testing" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Human thinking and auditing.
Will find some external team to do a professional audit.
", "keywords": [ "professional", "audit" ] }, "bounties": { "question": "Other bounties?", "answer": "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.
Same thing needs to exist for desktop software. Need a simple desktop wallet that accepts any kind of access to payments.
", "keywords": [ "payment", "wallet", "metamask", "access" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "There is no tooling or anything related to state channels that is trusted yet.
Need the MEW of state channels.
", "keywords": [ "state_channel", "mew", "tooling" ] } }, "3": { "name": "Mike Goldin", "who_what": { "question": "Who are you and what are you working on?", "answer": "Software developer at Consensys
Known 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.
TCR 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.
Adchain allows publishers and suppliers to find each other on a p2p.
By using TCRs to curate who may participate, cut out middlemen as well as bad actors.
Focus is on onboarding.
", "keywords": [ "type", "tcr", "consensy", "adchain", "developer", "onboarding", "design", "deploy", "ethereum", "token" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle, useful as a testing framework.
Solidity linter, Sol Lint. Not super good, but alright. Eventually, I want an Airbnb javascript plugin for ES Lint.
Ganache Test-RPC
Eth.js sometimes
", "keywords": [ "truffle", "javascript", "ganache" ] }, "testing": { "question": "How do you handle testing?", "answer": "Writes tests in Javascript
Sol Coverage tool
Wants 100% code, branch etc.
Github is part of testing workflow because of code reviews
How do you handle smart contract verification and security?
Also Josh Cassidy
", "keywords": [ "security", "github", "smart_contract", "test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Pretty cool to have more languages for the EVM. Solidity is only reliable one. Yoichi’s Bamboo is moving along.
", "keywords": [ "evm", "solidity", "bamboo" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Fuzz Testing and formal verification desired.
", "keywords": [ "formal_verification" ] } }, "4": { "name": "Oleksii", "who_what": { "question": "Who are you and what are you working on?", "answer": "Started working with smart contracts in early 2016.
Started by writing tests using Truffle for other people’s contracts.
Then, started educating himself on Solidity, became a smart contract developer.
What do you do at Ambisafe?
Do custom development for clients.
Our own products: e.g. webhooks for contract calls.
Scalable supernode solution – logic to make the node robust, etc
Platform to issue tokens. Fixed set of contracts, but for every new token, they deploy a new contract as a gateway.
Gateway token contract – implements specific logic of different tokens. Fees, etc.
+ Toolkit for DevOps / deployment:
Javascript functions to solve common problems, tx propagation issues, …
Tx propagation issues: sometimes your node gets a tx, but doesn’t propagate to any other ones. Mostly seen in Parity.
Deployment scripts
Checking that the gas that’s going to be spent; if enough gas is provided.
Scripts to collect info from the blockchain, doing sanity checks to make sure it’s all good before proceeding, then collecting data after, …
COULD THIS BE A BOUNTY TOOL?
Cloning of contracts.
Most of their contracts don’t copy any code anymore.
", "keywords": [ "gas", "scalable", "ambisafe", "issue", "token_contract", "deployment", "client", "javascript", "blockchain", "bounty", "deploy", "parity", "devop", "test", "token", "truffle", "smart_contract", "platform", "tx", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "We have written our own tools which tell us, for instance, that “this variable is never used.”
Also includes optimizations to improve gas usage –– e.g. read address value and store in memory before loop, then call into it.
For contract address, for state variables, etc.
", "keywords": [ "gas", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "5": { "name": "Brett Sun", "who_what": { "question": "Who are you and what are you working on?", "answer": "Working on Aragon entirely.
The end goal is to create a network between organisations that live on Ethereum (and potentially other platforms in the future).
This required a lot of foundational features.
A network of organisations requires organisations in the first place! So we have been working for the last year to build these.
We are now switching gears to think about what a network between the orgs will really look like.
We 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.
Two key pieces to this sort of work:
Controlling money.
Controlling permissions.
We also provide a lot of UI components on top of the contracts that we are writing.
The 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.
Should 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.
Hooking up your own apps, and designing your own interfaces to handle certain complex behaviour
", "keywords": [ "ui", "organization", "rinkeby", "aragon", "network", "permission", "resource", "ethereum", "design", "aragon_o", "platform", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Four categories:
EVM and lower level stuff:
A lot of our problems have been solved by solidity 0.5 pragma
Revert with reason! Should be better for error logging.
Dynamically-sized parameters inside the EVM. We did not have an opcode before Byzantium that could have handled returndatasize with dynamically-sized stuff.
We 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.
Smart contracts:
Not a lot of great tools here yet, especially around testing. This seems to be a fairly obvious hole.
Not a big fan of Truffle, even though everyone seems to use it. It is especially slow when compiling.
Solc 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?
Dapphub 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.
We 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.
There 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.
We do this, as it is especially helpful for auditiability.
Dev tooling that allows people to easily build aragon applications:
It’s tough to develop Ethereum applications right because there are a lot of things you need to spin up yourself.
Deploy a local chain, deploy your contracts onto it, and then only with that done can you start building a UI linked to that chain.
Not 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.
ENS 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.
This produces a lot of friction, both internally and externally, so we have this goal to simplify it all.
Ganache 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.
However, when you tell Ganache to run from the snapshot, if you do anything on the chain, it overwrites everything.
So you actually need two snapshots and some patience to get things right.
We also need to deploy things onto IPFS, which adds another barrier for users wanting to get going with local development.
So, we have tried to build this command into aragon-cli, called “aragon run” that handles everything for you.
Based 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.
UI:
Not too much in terms of Ethereum-related tooling - a lot is just normal, front-end javascript.
Major frustration is web3.js. There are just so many things wrong with that package… “Every day is new adventure when using web3”.
Pretty much every time we have had to do something for a deadline, we have run into issue with it that have delayed us.
i.e. in Buenos Aires, we wanted a mainnet launch for our Survey App, for which we need websockets and https.
We 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?
Took some hours to play with all the different settings before realising that the latest version of web3 doesn’t support websockets. Downgrading then works, but the previous package didn’t have some other functions we needed.
Relied on getting events to process changed information in the UI. However, the event handler in one particular version of the package would send some events in the error callback as opposed to the actual one and we were totally baffled how that could even be.
", "keywords": [ "minimetoken", "design", "ethpm", "ens", "contract", "ui", "evm", "solc", "aragon", "ethereum", "test", "ganache", "websocket", "smart_contract", "apm", "dapphub", "tooling", "javascript", "ipfs", "solidity", "error", "tool", "github", "truffle", "issue", "event", "deploy", "parity", "log" ] }, "testing": { "question": "How do you handle testing?", "answer": "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).
All 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.
", "keywords": [ "ci", "solc", "issue", "compiler", "security", "audit", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Human audits only right now.
Trailofbits 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.
A 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.
Tried 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.
", "keywords": [ "oyente" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "A nice debugger! Please…
More 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...
", "keywords": [ "event", "infrastructure", "dapp" ] } }, "6": { "name": "Jorge Izquierdo", "who_what": { "question": "Who are you and what are you working on?", "answer": "Aragon - Decentralized Governance platform
We had a feeling that they had to go deeper into the stack to launch Aragon.
What we’ve built:
We’ve built two different interpreters:
Language for ACLs
Language for tx descriptions, similar to Natspec.
Allows you to do calls to smart contracts; but really basic stuff;
Built 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.
Ruby on Rails abstraction on-top of the data layer.
Problem here: we don’t have any servers, we are a real dApp. Every single user has to compute entire state of the dApp.
Backend protocol / caching protocol / event-processing.
Upgradability stack.
Tooling to update storage etc correctly.
Trustless signer: help people understand their tx before sending the tx.
Working with metamask on this.
Our own CLI tooling
We have a package manager – backend to our app store
", "keywords": [ "trustless", "governance", "protocol", "tooling", "acl", "aragon", "event", "developer", "database", "dapp", "backend", "platform", "decentralized", "tx", "contract", "stack" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Infura that is more decentralized. A full-node infrastructure[a].
An open-source explorer.
", "keywords": [ "open_source", "infura", "decentralized", "infrastructure" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "7": { "name": "Jack Peterson and Sparkle", "who_what": { "question": "Who are you and what are you working on?", "answer": "", "keywords": [] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Back-end: Visual Studio Code with docker images that run pythereum for unit tests.
Solidity compiler - Solium linter everyday
Integration tests run against Geth/Parity nodes
Custom libraries -- all their own RPC code.
No web3.js (ETH.js libraries are better)
Can run locally or dockerized - have a CI pipeline (Travis)
Push to Github and deploy to Rinkeby
Custom 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
Truffle is used for this -- very challenging because it lacks deep modularity and customizability.
Failed 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).
There is definitely more work to get Truffle smooth for everyone
Actual contracts / delegate contracts -- build system is incredibly specific to their framework and difficult to adapt/customise.
Use Geth / Parity
UI -- react / redux.
Augur node is typescript ..
Lots of small things -- middleware library called ethereumjs-blockstream.
Library for generating keys and key files -- keythereum.
Key management is tough -- self signing (so can leave unlocked Geth instance, which is not good either)
", "keywords": [ "ci", "testrpc", "library", "typescript", "rpc", "keythereum", "contract", "ui", "test", "error", "github", "docker", "dependency", "truffle", "geth", "rinkeby", "augur", "ethereumj", "travis", "deploy", "parity", "integration_test" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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).
Biggest problem - always has been - test thoroughly and comb through the code. Use static analysis tools. The biggest thing holding us back:
Maybe better standards for writing this stuff (NASA)
Create linting rules?
Have 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.
", "keywords": [ "oyente", "linting", "static_analysis", "error", "test", "formal_verification", "unit_test" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Setting breakpoints in tests!
Salesforce 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).
Having clean Dev Nth without 30 things to set up:
React project will need to talk to Geth / IPFS / local = lot of setup is irritating.
If a transaction fails, the logs don’t get written. This needs to be in the EVM
Having many slacks is a big problem. We should have 1 slack with all developers.
Documentation is also terrible.
What documentation would you like to see?
Tooling / documentation / community takes like a decade to develop. (Check Kauri for a possible solution)
“How does Geth estimate Gas” - need to ask a bunch of people and it’s not written anywhere.
How 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.)
Issues 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.
", "keywords": [ "network", "community", "evm", "bounty", "gitcoin", "ethereum", "test", "kauri", "gas", "tooling", "ipfs", "documentation", "geth", "open", "react", "status", "issue", "developer", "cost", "log", "breakpoint", "slack" ] } }, "8": { "name": "Joey Krug", "who_what": { "question": "Who are you and what are you working on?", "answer": "Co-Chief Investment Officer at Pantera Capital and Co-Founder @ Augur.
", "keywords": [ "augur" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "At Augur, stack is different as it’s a bit older.
IDE: 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.
More than 5-10 smart contracts, beyond ERC20 and ERC-721, now Remix will fall apart
UI is a big clunky as you add more contracts
It’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.
", "keywords": [ "ui", "sublime", "ide", "vim", "augur", "static_analysis", "syntax_highlighting", "remix", "integration", "test", "smart_contract", "emacs", "contract", "stack" ] }, "testing": { "question": "How do you handle testing?", "answer": "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.
UX blockflow IDEO for Truffle, doesn’t need to be rewritten but needs to be improved.
", "keywords": [ "investor", "test_suite", "js", "test", "truffle", "stack" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
Tools 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.
", "keywords": [ "oyente", "ci", "multisig", "mythril", "smart_contract" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
From an investor standpoint these dev tools need to be improved.
", "keywords": [ "investor", "analysis", "test" ] } }, "9": { "name": "Mark Beylin", "who_what": { "question": "Who are you and what are you working on?", "answer": "Creator of the Bounties Network. Bounties on any task in any Ethereum token. Frontend that relies on Infura and IPFS.
Infura doesn’t let you listen for events. They have websocket capabilities that may be in beta right now.
Users use metamask for calls and transactions on it
I am the only solidity developer throughout its life.
", "keywords": [ "event", "transaction", "network", "infura", "bounty", "ipfs", "solidity", "developer", "websocket" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "I know and use the solium linter.
Use truffle, testrpc. I love Remix.
Use Remix for deployment. Feels like I can trust remix to work as it’s meant to.
Web3JS, BigNumber, site is built on React.
IPFS JS library.
Blockies react library.
", "keywords": [ "testrpc", "blockie", "library", "deployment", "ipfs", "remix", "bignumber", "react" ] }, "testing": { "question": "How do you handle testing?", "answer": "Mocha tests using Truffle and testrpc.
Also use Rinkeby for when deploying staging versions.
", "keywords": [ "truffle", "deploy", "rinkeby", "testrpc" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Consensys diligence is an auditing team available for their teams.
Argus (Berkeley audits chain)
Didn’t find anything in our latest audit
Diligence at Consensys later found a re-entrancy vulnerability
Oyente also missed the re-entrancy bug(!!)
Having bug bounties in general is a good standard
", "keywords": [ "oyente", "vulnerability", "consensy", "argus", "audit" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Better querying possibilities on the state of contracts. Better indexing to do this. Even something that will just shoot results into a SQL table.
A good wiki that is endorsed by the foundation but curated by the community.
E.g. “How to do X”
E.g. “What is X”
People don’t know what they don’t know
", "keywords": [ "community", "query", "sql" ] } }, "10": { "name": "Aidan Hyman", "who_what": { "question": "Who are you and what are you working on?", "answer": "Working with parity and geth and parity-bridge. Optimising the EVM for bespoke needs - could be for clients, for enterprises. Lower level focus.
Create tools and mechanisms for people to utilise the tech as easily as possible.
Collaborating with Aion & Shyft on potential implementation of a bridge.
Both on top of parity-bridge, which has some limitations:
Made only to work with POA.
Data availability for token information, following delegate_calls and not events.
Suggest work with Jay Rush and maybe add them into the team!!
", "keywords": [ "bridge", "evm", "event", "client", "aion", "parity_bridge", "shyft", "token" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle
Lack 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.
If 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.
Talk 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.
Parity and Geth
Also speak with David and Greg.
Use 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.
Rust is a more obscure language and people lack experience, hence geth is somewhat easier to use and troubleshoot.
Geth has a bigger community, but the actual people developing the client aren’t as readily available as Parity.
MetaMask for frontend development
Were 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.
Mythril
Huge frustrations with this tool. Getting it running is a pain in the ass.
If 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.
Could 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).
Educational tool for stupid web devs like me to learn about how opcodes actually work and are composed in the EVM.
Regular rust and node related stuff (also some go stuff).
Are there tools from these arenas that don’t exist in Ethereum which would be really cool?
We 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.
The 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.
Try to use ethers.js as much as possible as opposed to web3
The 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.
Polymath 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.
You 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.
Gave solidity and parity/EVM workshops:
EVM 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.
Whereas 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.
This is a community-wide failure that we need to focus on - for someone with a CompSci degree, solidity is crazy, but the stack is not!!
Bounty for cleaning up the yellow paper. Speak with David about this and his more in-depth version of the yellow paper.
Only ever hindered by delivering work because of MetaMask. Event and event monitoring between different networks was a fix that took a long time to be fixed. They have updated since and we haven’t done any more work there since.
", "keywords": [ "trace", "js", "network", "open_source", "community", "decentralized", "metamask", "wasm", "evm", "wallet", "mythril", "bounty", "ethereum", "test", "smart_contract", "client", "solidity", "truffle", "geth", "open", "stack", "mm", "issue", "polymath", "bot", "event", "parity" ] }, "testing": { "question": "How do you handle testing?", "answer": "Talk with Stu, who handles all the testing stuff.
Used 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.
Such a focus on formal verification in Solidity (but who even knows if it really matters?).
Not doing fuzz testing for instance, and it seems like a lot of these requests are based on assumptions that have not been proven.
No-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.
Again, modularity is what matters most.
Both unit and functional test as necessary. Unit testing seems more standard. Mocha and chai within truffle for the most part.
Ethereum-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.
", "keywords": [ "js", "mythril", "test_suite", "solidity", "bounty", "ethereum", "vm", "truffle", "test", "formal_verification", "assumption", "unit_test", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
Even 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.
", "keywords": [ "mythril", "ide", "evm", "stack" ] } }, "11": { "name": "Greg, Stu, David", "who_what": { "question": "Who are you and what are you working on?", "answer": "David: EVM layer stuff: interactions between opcodes, JS dev and web3 also comes into this at the other side
Greg: Reimplementation and adding functionality to the EVM and a lot of “bridge work”
Setting up bridges, working with parity bridge and other existing contracts
Added efficiencies for personal needs to types when blocks are getting written. Basically recreated in the EVM to get a sender.
Way blocks are written into the merkle tree.
Parity 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.
Stu: solidity and PM (managing groups of people working at that layer of the stack), building smart contracts for clients
", "keywords": [ "type", "bridge", "evm", "js", "client", "solidity", "parity_bridge", "smart_contract", "pm", "contract", "stack" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "JetBrains suite as an IDE. Remix comes in there for extra convenience but has it faults and is not totally integrated.
Biggest 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 ;)
Pass in data as strings and not having it parsed as strings is frustrating.
Will 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.
Debugger has not really been touched since the first version. Critical software lagging behind is not good. Still better than the truffle debugger though.
EVMLab - 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.
Web3 and truffle sometimes, but not often. Often Remix and a couple RPC calls with console.log()s suffice.
Looking over Mithril and visualisation of the control flow seems really interesting. Handles all the low hanging fruit, as an automated system should.
", "keywords": [ "jetbrain", "ide", "mithril", "hack", "remix", "jquery", "log", "evmlab", "infrastructure", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "Mostly unit tests in mocha and chai.
Mostly using Travis to automate the pipeline.
Projects are fairly young and PoC - so not necessarily a major concern at this point.
If not already mentioned, are there any libraries you rely on regularly?
", "keywords": [ "unit_test", "library", "travis" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Mythril, as mentioned above.
", "keywords": [ "mythril" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "EVMLab certainly has some of the features required, but they are very inaccessible
Directly execute arbitrary code and trace through it in nice fashion that is not just some JSON output.
Need to be able to step through those traces easily, which is also not possible there currently.
Go 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.
Some level of standardisation around bridges and agreement about how they should be structured.
What does interoperability actually mean in this context?
", "keywords": [ "bridge", "trace", "execute", "parity", "open_source", "context", "evmlab" ] } }, "12": { "name": "Jon Maurelian", "who_what": { "question": "Who are you and what are you working on?", "answer": "I work at Consensys Diligence doing audits; similar to Zeppelin.
Also, I do technical communications / writing blog posts about best practices around security / Consensys docs / token repos.
", "keywords": [ "security", "consensy", "zeppelin", "token" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "We use Truffle a lot (never had to use Dapple or Embark)
Zeppelin used by clients -- would like to use EPM more
Runs a Geth node myself
Solhint linter
Solidity Coverage is test measurement coverage tool
ETHGasReporter (Takes your Mocha reports and says how much Gas your test used.)
Would like to see a fuzz tester.
Excited to learn more formal verification + bringing into practice – intro to Sergio?
", "keywords": [ "embark", "ethgasreport", "mocha", "gas", "tester", "client", "test", "formal_verification", "solhint", "zeppelin" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "13": { "name": "Nick Dodson", "who_what": { "question": "Who are you and what are you working on?", "answer": "Working on experimental infrastructure. ARES, GovernX.
Building off-chain stuff - in order to conduct governance in organizational structures, most of the work is off-chain.
Will also be doing on-chain governance, where they build DAPPs for ICO’s
Infrastructure level stuff: infura.
", "keywords": [ "governance", "ico", "are", "infura", "dapp", "governx", "infrastructure" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Solidity Compiler
The 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.
Solc 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).
Could write `solidity` in backticks and have it compiled all in same file.
Would make experimentation and testing much easier and faster. Could potentially provide some specs/API for this. Will provide further specs via email.
Trying to build complex systems with 20 contracts and everytime need to wait 20 minutes
TestRPC + Geth Client
Not well maintained - ask Truffle team.
People 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.
Was working on Geth library that allowed you to run in Mac / PC with JS
Used Geth like Testrpc - allowed you to test contract codes against all clients (Geth / RPC / Parity)
Never finished, but definitely needed.
If 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.
Can 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)
Truffle uses Ganache which is ETH JS VM - this isn’t used in production.
Truffle involves hassle of having to download run and configure GETH
Maybe a wrapper or easy install script - run Geth like TestRPC
", "keywords": [ "testrpc", "solc", "library", "production", "js", "compiler", "client", "solidity", "nodejs", "parity", "vm", "email", "test", "ganache", "truffle", "rpc", "geth", "contract", "api", "wrapper" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Mythril will be useful when in full bloom - need more oversight on contracts in general
", "keywords": [ "mythril", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "14": { "name": "Ilan Benbrith", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
The course is for experienced developers - experience with languages/git required.
Overall objective is to attract people to and grow the Ethereum community
Content creation, assignments, course, customer/student support, external resources, connection with Consensys mentors
The 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.
Teaching them the setup and tools they’ll need for the program (Truffle, Ganache, Remix, etc.)
Then EVM, Solidity/smart contracts, connecting a front end with React Native
Security smart contracting and auditing with help from ConsenSys Diligence
Finally, different integrations (IPFS, Oracalize, etc.) and design patterns of different teams.
LLL, Assembly language for the EVM, Vyper.
Ethereum Improvement proposals/ Ethereum Request for Comments processes
", "keywords": [ "mindset", "remix", "design", "integration", "contract", "evm", "course", "ethereum", "ganache", "pm", "consensy", "ipfs", "mentor", "truffle", "react", "content", "lll", "developer", "resource", "security", "context", "blockchain", "vyper" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle, Ganache, Remix, Metamask etc.
Front end
React Native
LLL, Front end libraries
We give wide exposure
", "keywords": [ "lll", "metamask", "remix", "library" ] }, "testing": { "question": "How do you handle testing?", "answer": "Truffle testing
Best practices resources
", "keywords": [ "resource" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Consensys Diligence provides some of the best resources and best practices online
", "keywords": [ "resource" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Drizzle is a really cool idea for front-end development
", "keywords": [] } }, "15": { "name": "Goncalo Sa", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
95% 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.
The goal is to eventually encompass everything related to Ethereum security.
I have always been hacking - a grey hat of sorts.
Built an ad tech startup, which had a built from scratch ad server that I did the architecture for.
Had a mobile app to tell Portuguese people what was happening in their city.
", "keywords": [ "security", "ethereum", "smart_contract", "evm" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "I used to use Remix a lot more than I do today (though I still use it heavily).
Use 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.
Visual debugging feature helps me a lot. It’s not perfect, though.
We’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.
Used mostly for automatic detection of errors.
Oyente is falling behind a bit, so I haven’t used it in a long time.
Manticore 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.
Have played with, but never tried to integrate, Enchidna into my workflow, as it is difficult to work with due largely to deadlines.
Rattle is closed source, so haven’t yet got around to playing with it.
I 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.
", "keywords": [ "query", "oyente", "antlr", "mythril", "solidity", "error", "manticore", "solidity_contract", "audit", "rattle" ] }, "testing": { "question": "How do you handle testing?", "answer": "Remix, Surya and Mythril as above.
Very small number of instances where I need to do something off chain, for which I will then use Truffle.
", "keywords": [ "mythril", "remix" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "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!
", "keywords": [ "community", "ethpm" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "A proper, local dummy client. I love the Truffle team and I love Ganache, which I use a lot.
I 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.
Using 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.
We haven’t really prepared for how to handle contracts across shards (coming months to years, who knows?).
We 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.
I 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.
We 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.
Mythril will also eWASM at some point before it goes into production.
", "keywords": [ "wasm", "consensus", "ewasm", "event", "transaction", "mythril", "client", "solidity", "production", "block_explorer", "design", "ganache", "truffle", "platform", "vyper", "contract" ] } }, "16": { "name": "Fabiano, Jordan, Nick", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
Back-end stuff reconciling state of the world between blockchain and their stuff
", "keywords": [ "cryptokittie", "shard", "blockchain" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "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.
", "keywords": [ "truffle", "deploy", "smart_contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "Standard testing and using community to audit contracts
", "keywords": [ "community", "contract", "audit" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Audit code: bounty hunt program, found one major one via community. Ran our own repo specifically for this on Github.
Community auditing through bounty programs.
", "keywords": [ "community", "github", "bounty", "audit" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "2 main areas with significant problems:
Data analytics and reconciliation btw on-chain and off-chain data.
Our 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.
Analytics is difficult. Web3 and Geth, have to hook into data. But there are too many hurdles to jump to get these.
In 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..
Part 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
", "keywords": [ "analytic", "reconciliation", "transaction", "deploy", "cryptokittie", "smart_contract", "geth", "tx" ] } }, "17": { "name": "Andy Milenius", "who_what": { "question": "Who are you and what are you working on?", "answer": "DappHub:
Working 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.
Made tools to make use of Solidity compiler & make Ethereum API & EVM simpler in general.
Formal verifications & contract safety.
", "keywords": [ "dapphub", "evm", "compiler", "solidity", "ethereum", "safety", "contract", "api" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "18": { "name": "Esteban Ordano", "who_what": { "question": "Who are you and what are you working on?", "answer": "I’m hiring two or three people – excellent engineers – to build tooling.
We’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.
Our infra:
MANA token which is an ERC20.
Auction of Land.
Land smart contract which is an NFT token standard.
Got tired of not hearing back re ERC non-fungibles improvements. Proposed alternative ERC.
Land registry of who owns which land parcel.
These link to IPFS or IPNS for content of land.
Decentralized exchange of land parcels.
Small 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.
We 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.
Auction was mostly an independent application – better UX, less fees
Why the auction was off-chain:
We 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.
Both 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.
Anyone in the auction everyone could act as an independent verifier of the auction.
We returned a receipt had a nonce ––
We can audit the whole auction. Can prove every bid that we received.
How we’ve been running auditing
We sold $16m worth of parcels of land.
We wanted to make sure that they weren’t messing up.
Not many people were checking – but a few did and even reported back some issues; community trusted them.
Would be best if this was run on a decentralized protocol so people didn’t have to trust these guys.
We’re building a voting scheme with MANA:
“How tall should this building be?”
We are repeating the same pattern as the auction.
Our voting scheme is offchain and non-binding, because the project is early enough that people can back out.
", "keywords": [ "cryptographic", "ipns", "nft", "token", "community", "fungible", "decentralized", "contract", "independent", "engineer", "protocol", "email", "browser", "verifier", "smart_contract", "ethalarm", "decentralized_exchange", "auction", "tooling", "ipfs", "audit", "content", "event", "issue", "blockchain" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Biggest request: have ERC20 upgraded to ERC223.
We have troubles with small re-orgs – transferring immediately upon approvals causes issues.
This was a problem with our code; hard to develop.
Have watchers on the Blockchain, and sending transaction to make correct transfer, e.g. for MANA token.
", "keywords": [ "blockchain", "issue", "watcher", "token" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "19": { "name": "Matias Bargas", "who_what": { "question": "Who are you and what are you working on?", "answer": "I used to be an investor, but came to crypto and Decentraland at the same time.
I 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.
It’s about the open philosophy, and break down the walls around the 1% of the 1% and diffuse power into the hands of everyone.
I was working on an online IDE for an in-house language at MuleSoft. Now the engineering manager at Decentraland.
", "keywords": [ "investor", "decentraland", "ide", "crypto" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "The whole Ethereum stack, basically.
Truffle
Integration 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.
If we are changing the world, why are we still thinking in narrow ways about how our tools should be used and by whom?
VS Code
React, typescript, nodejs
Bablyon.js as an engine for VR
Web3
One of team members rewrote web3 into typescript for EthBuenosAires and all the tests are passing! Will post a link here after the hackathon.
There were typos there!
There was functionality not working (and there are billions of $’s running on top of it!)
IPFS for decentralized deployments.
Scalability 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.
The IPFS cluster is still in alpha and not as stable as we need it to be.
We 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.
I haven’t used this yet, but this seems to be an interesting tool: https://github.com/nomiclabs/buidler
", "keywords": [ "issue", "js", "deployment", "ipfs", "vs_code", "react", "typescript", "nodejs", "ethereum", "deploy", "integration", "test", "truffle", "decentralized", "stack" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
You 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.
A complete set of tools for testing. Truffle is not adaptable enough.
The work being done by Zeppelin on securing contracts and providing best practices around how to use audited contracts is great.
", "keywords": [ "zeppelin", "event", "deploy", "audit", "truffle", "decentralized", "infrastructure", "contract" ] } }, "20": { "name": "Nadav Hollander", "who_what": { "question": "Who are you and what are you working on?", "answer": "Building Dharma - open protocol for tokenized debt
Pretty much exclusively at the contract level, sometimes using stuff like libraries that wrap around contracts.
", "keywords": [ "protocol", "library", "dharma", "open", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "I like to use Typescript for testing.
0x team built a great tool for generating typescript tests from ABI’s
Using truffle to test.
", "keywords": [ "truffle", "test", "typescript" ] }, "testing": { "question": "How do you handle testing?", "answer": "Truffle to write JS unit tests.
** There are not good mocking libraries for solidity **
Had to roll my own mocking contracts for testing
A better native solidity testing framework with mocking would be awesome
No manual testing.
It’s still pretty painful to do this too
", "keywords": [ "test", "solidity", "library" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Write down in plain text documents what the invariants are for the contracts. Just very clear human speak for how the contract should behave.
Then write unit tests relentlessly.
Ideally, there would be code review, but he is coding solo in his stuff write now.
Finding an audit is a crappy process. No information on who is doing it, what prices look like, which auditors are good / have good reputations.
Talked to zeppelin
Talked to Consensys diligence
Talked to Quantstamp
", "keywords": [ "zeppelin", "invariant", "quantstamp", "audit", "unit_test", "code_review", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "A GREAT SOLIDITY DEBUGGER
A 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.
Also let you set up rules on it like locking up deposits for a week between the side chain and the main chain.
", "keywords": [ "lock", "deposit", "solidity", "history" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Good logging and debugging
Setting up your own side chain easily to test things on because it would be way faster
", "keywords": [ "test", "log" ] } }, "21": { "name": "Alex van de Sande", "who_what": { "question": "Who are you and what are you working on?", "answer": "Working on Mist, the Ethereum browser.
Developers contributing open-source.
There’s a wall between core team & open-source team.
Would love for people to be paid reliably for features.
3 Developers. Talk on Discord.
Current experimentations in paying open-source developers:
Colony
Commit F
We want beter Github integration. Now possible with Status Open Bounties and Gitcoin etc.
", "keywords": [ "status", "developer", "bounty", "gitcoin", "ethereum", "github", "integration", "open_source", "browser", "colony", "open", "mist" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "People build new features, we check, and then approve it.
We’ve had issues –
Meteor.js migrating to React.
", "keywords": [ "issue", "js", "react" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Finding talented people is very hard. They are in such high demand. Trying to get people out of school. Online courses in Solidity.
Web developers, software engineers.
Separate recruiting approaches for the Foundation.
", "keywords": [ "recruiting", "developer", "course", "engineer" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "22": { "name": "Nick Johnson", "who_what": { "question": "Who are you and what are you working on?", "answer": "ENS: documentation, smart contracts, UI’s,
Auditing other smart contracts
Other smart contracts
Ether cards
Offchain: dev tool, EVM static analysis tool,
", "keywords": [ "ui", "evm", "static_analysis", "documentation", "smart_contract", "ens" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Open Zeppelin tools are increasingly good. But try to keep the smart contracts as small as possible
Just web3 itself in terms of javascript
ETH Gas station and etherscan are useful for different reasons
", "keywords": [ "smart_contract", "javascript", "etherscan" ] }, "testing": { "question": "How do you handle testing?", "answer": "Truffle unit testing with mocha
Added built in testrpc
Testrpc still doesn’t have big number support for certain signatures so we have to fire up a geth node
", "keywords": [ "signature", "mocha", "testrpc", "test", "geth" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Write a spec and define edge cases and corner cases
Lots of unit tests
Make a point of testing where you intentionally break
Ultimately get it audited
How will this get easier for beginners?
Open source solidity libraries so that less code needs to actually be written by beginners (just 10 lines of customization)
Build some of these best practices into static analysis tools (linterns on steroids)
Solicit crowdfunding to pay for the audits of projects that the mainstream is interested in
Open Zeppelin appears to be the best open source solidity library out there
", "keywords": [ "crowdfunding", "library", "static_analysis", "solidity", "open_source", "audit", "unit_test", "open", "zeppelin", "spec" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Byzantium added return data size (prevents arbitrary return data size limits). Once solidity implements this, it will be possible to return strings and stuff.
Automated updatable smart contract?
", "keywords": [ "limit", "smart_contract", "solidity" ] } }, "23": { "name": "Elena Nadolinski", "who_what": { "question": "Who are you and what are you working on?", "answer": "Last 6 months have been working on Solidity, Ethmoji (like Gravitar for Ethereum).
Went 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!
OpenZeppelin came up to her and invited to talk at ETHBA.
With EthMoji wanted to make it the best smart contract as possible, wanted to make it upgradeable.
", "keywords": [ "ethmoji", "ethwaterloo", "ethdenver", "nft", "ethereum", "test", "openzeppelin", "smart_contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "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.
OpenZeppelin, played around with ZeppelinOS but would use it more in the future.
VSCode with Solidity plug-in, almost never have problems.
Eth-gas-reporter is amazing :)
Command line tool for code coverage, Solidity-coverage is a mocha plug-in
", "keywords": [ "embark", "mocha", "solidity", "remix", "openzeppelin" ] }, "testing": { "question": "How do you handle testing?", "answer": "Truffle for testing. Force people to do TTD in events!
Truffle is not efficient in deploying things, can have a deployer contract that handles with more gas efficiency.
", "keywords": [ "gas", "event", "deploy", "truffle", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Documentation
Debugging, 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
Something 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.
Design 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.
Figma 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.
", "keywords": [ "ide", "developer", "infura", "remix", "crypto", "documentation", "design", "open_source", "browser", "blockchain" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
Documentation, for a beginner starting out it’s extremely difficult. Not that many good tutorials on how to use technologies together.
Index of good tutorials. For IPFS in a smart contract. Want more deeper tutorials. Want to understand the why.
", "keywords": [ "tutorial", "ipfs", "travis", "documentation", "truffle", "smart_contract", "contract" ] } }, "24": { "name": "Swaroop", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
Once 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.
Demoed 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.
", "keywords": [ "ide", "web_developer", "transaction", "event", "developer", "hack", "private_key", "remix", "deploy", "integration", "ethvigil", "testnet", "token", "email", "blockchain", "rpc", "rest", "contract", "slack", "api" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Mostly custom tools. Started with web3, started with Truffle but was running into a lot trouble using them so rolled their own.
", "keywords": [ "truffle" ] }, "testing": { "question": "How do you handle testing?", "answer": "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.
", "keywords": [ "unit_test", "integration", "test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
Recommend that our customers use Truffle, Ganache, etc.
", "keywords": [ "issue", "json_rpc", "developer", "ganache" ] } }, "25": { "name": "Alex Beregszazzi & Pawel Bylica", "who_what": { "question": "Who are you and what are you working on?", "answer": "Pawel - focused on VM in general, spent a lot of time designing / optimizing the EVM for the future.
Experimenting with new ways to make the VM faster for future upgrades
Classic code optimization - added some small features to EVM (like Revert / Return Data Buffer / Shift Operators)
Works mostly with Alex -- changes in Byzantium were with Christian
Joined 2-3 months ago
Maintained C++ code base for Ethereum client -- experience with EVM
Alex
Started with building dApps, contracts, UIs – everything was broken in 2015.
Then jumped into proposing things and fixing things;
Solidity
Testing
Javascript
Led to working on testrpc & ganache-core
Worked on Trezor, and build a dApp for it.
Ended up with all these other issues: cpp-ethereum; testrpc; RPC methods.
Tried to raise issues, and sometimes they end up in improvements.
Spends most of his time in Solidity design.
eWASM – 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).
", "keywords": [ "evm", "testrpc", "ewasm", "issue", "javascript", "solidity", "dapp", "design", "vm", "rpc", "trezor", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "26": { "name": "Christian Reitwiessner", "who_what": { "question": "Who are you and what are you working on?", "answer": "90% of my time: design of Solidity language and its implementation
Formal verification part of the language –
Deprioritized over the last 2 months. Will take on again in April.
Other projects:
General research
Less research re sharding or plasma – More research on computational scalability of SNARKs, STARKs, Truebit
Handed off cpp-ethereum to Pavel – not working on it as much.
", "keywords": [ "sharding", "snark", "solidity", "design", "research", "formal_verification", "plasma", "stark", "truebit" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Gas profiling:
Solidity does some upper-bound gas cost estimation – but its not very useful because it’s just an upper bound.
How to calculate: run the EVM with specific inputs?
Or: 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.
Solidity – 16 stack slots issue:
Soon: we’ll have structs, and this will be less of an issue.
When we have IULIA, this requirement will go away.
When IULIA compiles to EVM, it can move variables from stack to memory, after analyzing which is used or not.
Interesting: IULIA will compile to eWASM.
Inlining common function calls:
We’re conservative when it comes to adding new features in the code generation flow.
We already have an optimizer for IULIA which does inlining; so that will resolve this.
The optimizer (in solc) has a switch which decides what to optimize for: code size, execution cost.
This exists, but is rather crude – it assumes every opcode is only run once and this assumption breaks down if you have a loop.
Have Remco share his 0x example with Christian – and how it could be improved in terms of gas estimation.
Constant delegation.
Have Remco to share example of hash not being calculated at compile-time.
Having a good technical writer – who can understand the technical details of Ethereum, and improve the documentation.
Another 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.
Improving the documentation for Solidity
They’re too deep inside this. Having an external viewpoint would be helpful.
In 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.
Integrating research software with development tooling & keeping them up to date.
Big example: Formal Verification software
Five or six tools that similar to Oyente.
Remix has a plugin architecture – possibly supports Oyente.
Idea for tool: being able to test very quickly if a contract implements an interface.
The problem is that you cannot enumerate the functions of a contract.
There’s a way to resolve this.
", "keywords": [ "remix", "contract", "evm", "solc", "ewasm", "bounty", "ethereum", "test", "iulia", "oyente", "gas", "tooling", "gas_cost", "solidity", "documentation", "stack", "issue", "gas_profil", "cost", "research", "slot", "assumption", "formal_verification" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "27": { "name": "Fabian Vogelsteller", "who_what": { "question": "Who are you and what are you working on?", "answer": "My future project: Lukso blockchain: EVM-based blockchain.
Working on industry-specific blockchains.
Built the Mist browser and Ethereum Wallet(worked with Alex van de Sande, who came up with the idea / design, and Fabian built it).
Works on web3.js. Proposed ERC20, ERC725/735 identity standard.
Joined Jan 2015 before mainnet. First person to make the user-facing / developer-facing tools intuitive. Simplified the RPC API.
My main focus now: half-time: web3.js & half-time: Lukso.
", "keywords": [ "wallet", "developer", "identity", "ethereum", "design", "browser", "blockchain", "rpc", "mist", "api" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Web3.js
History:
Initially, it was built by Jeffrey Wilke.
Then Marek was working on it. Then I joined.
After Marek left, I took over. I’ve been on it on my own for the last and a half year.
Did a full refactor. I changed everything to be more intuitive, simple, how I thought it should be.
Changed 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.
It’s harder now to make global changes across Ethereum – because of different clients, agreements take time
E.g. Parity has the Pub/Sub model, and a parity-Pub/Sub model.
A lot of work around promises resolving based on conditions
Better documentation.
Account generation, key generation, signing, …
ABI Encoding, decoding, all are exposed.
Going forward: the API is good now, so someone should simplify the internals.
e.g. scrypt package is super large.
We hired a new person who starts in July.
The security model: either the person developing web3 is trusted, or you need a lot of people looking at it.
Would love to at some point decentralize & bountify the project.
The project doesn’t need too many more people. The main work is done, but future addition could take more work.
There are two groups around the identity profile now:
Put it off-chain: for privacy etc.
Put it on-chain: ERC725.
", "keywords": [ "subscribe", "transaction", "client", "identity", "security", "ethereum", "history", "api" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Need good IDEs:
Remix is good, but has problems.
Omkara – Remix for Atom. Sophisticated Solidity IDE for the Atom browser
This project can get a lot bigger. Could add debugging.
Formal verification
Write specifications for smart contract implementations, generated proofs that can be tested against EVM code.
Smart contract security / best practices
Also comes down to an editor – gives you recommendations, formatting, etc.
More examples in the Solidity documentation
There’s someone at the EF working on documentation now.
Unit-testing for Solidity contracts
Dapple: a tool for testing Solidity contracts using Solidity contracts – unmaintained for 2 years now.
How is it that we don’t have unit-testing for Solidity contracts?!
OpenZeppelin works on these audited pieces.
Ideas:
“Results-based” bounties.
having smaller tasks, having a lot of eyes on the project and setting smaller bounties.
Incentive structure for the reviewers & maintainers.
Idea: standing bug-bounties for large ecosystem projects & contracts, funded by EF.
", "keywords": [ "atom", "remix", "incentive", "contract", "evm", "bounty", "unit_testing", "test", "browser", "smart_contract", "maintainer", "solidity", "documentation", "solidity_contract", "audit", "ide", "reviewer", "omkara", "security", "openzeppelin", "formal_verification" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "28": { "name": "Hudson Jameson", "who_what": { "question": "Who are you and what are you working on?", "answer": "Mainly focused on solidity smart contracts. A little node JS and Java but not very good at it.
", "keywords": [ "js", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Remix, MyEtherWallet, MetaMask
", "keywords": [ "metamask", "myetherwallet", "remix" ] }, "testing": { "question": "How do you handle testing?", "answer": "Have been using Truffle more lately but was mostly just using Remix before.
Write 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.
", "keywords": [ "truffle", "deploy", "metamask", "remix" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Use the Remix tool to just scan for general bugs.
Wanted to use Oyente, but don’t know how to use it
Remix is thinking about being modular to the point where you can just plug in your own about module - that would be awesome to see.
", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Dev Grants from the Foundation
Ethereum foundation had 2 iterations of this program
Get some money to build something at the protocol-level
The foundation is looking into revising the process.
", "keywords": [ "ethereum", "protocol" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Remix combines an editor with a deployment mechanism and that’s what I like about it.
EthMix 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.
Something that automatically uploads the contract to ENS.
", "keywords": [ "ide", "deployment", "remix", "ethmix", "ens", "contract" ] } }, "29": { "name": "Martin Swende", "who_what": { "question": "Who are you and what are you working on?", "answer": "I was a security professional, doing consulting, came into Ethereum a couple of years ago solving bounties for VMs.
October 2016 - became Head of Security at The Foundation.
Monitoring mainnet.
Being 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.
So, 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.
But can’t do it vice versa - been nagging Parity to add that end point so we can do the same process in reverse.
Geth 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.
Optimizations in geth which made block processing faster in the past month. You can also monitor for performance, not just security...
Shanghai attacks taught us that performance very much related to security.
P2P 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)
Would be difficult as an add-on (need node keys, decrypt data, etc.), Much simpler to do within a client. Protocol layer in Geth.
Build tools for analysis, especially when things are going wrong: hacks, network problems.
E.g. transaction propagation when network was overloaded with txes going back & forth between parity and Geth.
Needs for lots of testing around hard forks as the existing tools were not sufficient to cover all cases.
Coverage 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.?
Another 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.
Caught 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.
If patched before hard fork - no problem. Beat the drums and tell everyone to upgrade.
If 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.
Examples 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.
There 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.
Developers 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.
Have built tools to detect this, so we consider it solved from a technical p.o.v.
Recommend 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.
Building something like Ethstats but more detailed. If there is a consensus failure, you might want to see exactly which tx in which block caused it. Nice to see blocks, txes and intermediate root hashes between each tx. Then you can see different post-state hash, i.e. that is where we should start looking.
Need detailed traces of exactly what happened in every opcode of this transaction.
One of the things I built in EVM Lab is a reproducer. Synthesises pre-state for that particular tx, then executes it and gives you a detailed trace from geth and parity that you can then compare.
Not much active development on EVM Lab. Use it mainly for investigating certain condition or opcode or potential attack. Pretty easy to put together desired scenario in an EVM assembly-like way by setting genesis you want and then run & benchmark it.
It is usable right now and I have no immediate plans to do anything in the near term. Might need some updates and it is not so user friendly.[a]
One of core devs for go-ethereum.
We want to expand - have 2 interns now, but had to turn someone away recently too. Send interested developers to Peter.
Working a lot with the signer, which was just merged in latest release. Standalone binary which can run off some secure enclave, USB armoury, parallel VM, some other machine on your network. Can be used for offline signing and has trusted UI.
Can be configured with particular rules written i.e. in JS. Definitely needs more work on the UI. has implemented one in python-qt and python-cleft. Can also be run in a console, with remote ports etc so you can decouple pvt keys from your daily computer.
Hoping MetaMask will integrate with it directly. Has spoken with Dan and another guy called Jordan building a tool called (?) which has integrated it already.
Hard problem: how to make it more secure for end users. Surf internet with unpatched browsers with 0 days and they get exploited. How can we improve upon that so that you have a sign what you see flow. Submit a tx, see the details of that tx when you approve it.
Unlock feature is most horrible thing he has seen where it will sign every tx sent to it for a given period.
I don’t do too much DApp development, so I’m not up to speed with capabilities of current tools and how they have matured over the last 6-8 months.
I have heard there is a debugger out now which I remember as being one of the main pain points.
", "keywords": [ "query", "trace", "consensus", "js", "network", "tx", "api", "metamask", "ui", "evm", "protocol", "bounty", "ethereum", "test", "deposit", "browser", "professional", "evm_lab", "gas", "tooling", "fuzzing", "client", "documentation", "vm", "docker", "geth", "stack", "react", "transaction", "analysis", "issue", "hack", "developer", "security", "parity", "execute", "cost" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "30": { "name": "Kevin Owocki", "who_what": { "question": "Who are you and what are you working on?", "answer": "I developed Gitcoin, a bounty (and tips) platform for incentivizing open source contributions.
Solve incentivisation problem of OSS, where it is highly strategically valuable but difficult to capture in real-time the value being created.
I want to bring more devs into the space - MAIN GOAL.
300 bounties fulfilled so far and recruiting opportunities for OSS developers
Consensys offered customers (projects creating bounties for pilot of gitcoin), funding, regulatory protection
Not totally interoperable for now with EthPrize, recruiting strategy etc. Bounties are just one of the tools to recruit developers
", "keywords": [ "consensy", "ethprize", "developer", "bounty", "gitcoin", "open_source", "regulatory", "platform", "recruit" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle for managing deployments and smart contract versioning
Web3Py, due to comfort with py and personal relationship
Django, Bootstrap, Metamask, Infura for Gitcoin Platform - which is mostly a standard web interface.
", "keywords": [ "deployment", "infura", "gitcoin", "versioning", "metamask", "django", "truffle", "smart_contract", "platform", "bootstrap" ] }, "testing": { "question": "How do you handle testing?", "answer": "Pytests with TravisCi
Using product. Use gitcoin to build gitcoin.
Selenium tests with native web3 functionality
", "keywords": [ "test", "gitcoin" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Gitcoin X EthPrize
More talent than fundable issues right now at Gitcoin - always looking for more cool stuff for the community to work on.
Happy to help.
", "keywords": [ "ethprize", "issue", "community", "gitcoin" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "31": { "name": "Quazia & RJ", "who_what": { "question": "Who are you and what are you working on?", "answer": "Giveth - Charity platform with three layers
Fairly complex contracts on-chain. Pushes the limits of gas limit. Making transactions is relatively expensive.
Off-chain stuff. We cache everything; we store images and profiles offchain, will eventually be on IPFS.
Some actions are not on-chain: “reviewing a milestone”.
", "keywords": [ "gas", "transaction", "ipfs", "limit", "platform", "giveth" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Remix vs. your local dev environment:
Can write code, deploy, and debug in Remix.
EVM Lab: written by Martin Swende; give it a tx hash; spits out opcodes, storage, memory.
RJ wrote source code mapping – doesn’t work for complex contracts. Show your contract code along with the opcodes.
We use it often. Simple CLI tools. Just need Web3 and a tx hash. Sounds AMAZING.
To be improved: bugs with reproducing certain transactions.
E.g. couldn’t recreate contract creations.
Source mappings.
", "keywords": [ "evm", "transaction", "remix", "deploy", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "Offchain stuff is not dispute related.
Gas limit issues:
Jordi wrote contracts to begin with – so WE had a good start.
Multiple 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.
Abstracting – one key-value contract that stores pointers to data.
Rest of data – stores all data. Mappings of hashes to boolean to structs / addresses / etc.
Leads to upgradability of contracts. To the parameters used in the logic.
Separate data from the application; let’s you iterate. The data contract is owned by the business logic, ETC.
Estimating gas / optimizing code:
To get gas limit: run it on testrpc. Easy.
Debugging is hard, after you start adding assembly in there.
Remix is hard for large contracts. Multiple contracts.
Testing flow:
We use Mocha + wrappers to generate contracts in Js.
Needed: better errors. e.g. if testrpc spit out more useful messages.
Deployment & CI:
We have Node scripts to do this. Async await. Pretty simple contract.
Jordi’s tool compiles everything into a single file; makes verification on Etherscan simpler.
", "keywords": [ "gas", "testrpc", "ci", "issue", "js", "deployment", "remix", "error", "etherscan", "rest", "wrapper", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "A solid debugger – needs a rare breed of dev to build.
Scaffolding tool for prototyping things –
To test a small contract before integrating with everything else.
Think this will standardize over time.
", "keywords": [ "test", "contract" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "32": { "name": "Griff Green", "who_what": { "question": "Who are you and what are you working on?", "answer": "3-tiered approach:
Blockchain smart contracts: liquid pledging; pledges that take control of authority and funds. Blockchain layer does the accounting.
Owner gets notified by email.
Bounty system: basically a chat room. Project discovery layer.
UI layer: reads off the blockchain, interacts with the blockchain.
", "keywords": [ "ui", "discovery", "bounty", "email", "blockchain", "pledge", "chat" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Use Feathers interface to do caching. Improves UX.
NPM. Etherscan. Metamask.
Set of tools that we made ourselves. We don’t use truffle because we were building smart contracts before truffle was a thing.
React. Remix.
", "keywords": [ "remix", "etherscan", "truffle", "smart_contract", "metamask", "react" ] }, "testing": { "question": "How do you handle testing?", "answer": "We lean on the community a lot and give them “sneak previews”. We let them to go through the UX, and watch what happens.
The same person does all the testing.
We do a lot of auditing for other projects. Audria does this. We have a lot of good auditors and always maintain 100% code coverage.
Use travis for CI.
Most bugs they see are about game theory & cryptoeconomics.
These come up in ad-hoc situations.
We try to isolate things into individuals. Clear interfaces.
We always wanted push to live mainnet right away, but...
Today we made the decision to go to testnet, because mainnet is so expensive.
Testnet is not real a test (since it’s not real money).
We’re going to have a testnet token that represents real Ether.
“Proof of Authority” using Rinkeby.
Using the Minime token controller. Multisig pays out based on what’s happening on testnet.
Ehter’s price has gone up, gas is high, so everything is super expensive.
BAD for our users.
This is game over for dApp developers.
If Ethereum cannot solve these issues, developers will leave.
RSA, Ubiq will have Solidity. But don’t have block explorers. White hat hacker group is looking into
Open-source Etherscan.
", "keywords": [ "ci", "gas", "game_theory", "decision", "rinkeby", "multisig", "cryptoeconomic", "developer", "code_coverage", "dapp", "issue", "solidity", "ethereum", "isolate", "test", "testnet", "token", "etherscan", "community", "open" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Scaling proof-of-authority.
Block explorer.
Ropsten testnet gas limit -> attacking with gas limit.
Open-ended: apply for a bounty with your own idea.
We 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.
", "keywords": [ "network", "bounty", "block_explorer", "security", "scale", "testnet", "open" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "33": { "name": "Jordi Baylina", "who_what": { "question": "Who are you and what are you working on?", "answer": "Experience: 35 years of programming; 3 years in blockchains.
Learning more everyday; exciting from a global perspective.
This tech can change society over time. We’ll see centralised power disappear, the world will become more trustless, people will take responsibility for themselves.
One of my first smart contracts was liquid democracy for the DAO.
Smart contracts for the white-hat group that originated from the DAO.
Wrote the Minime contract – maybe not the best time now because of gas costs, but it is an interesting smart contract.
Did the Status ICO.
Liquid pledging for Giveth.
Pushing DappNode - should be released soon and is really important for true decentralization.
Audits – for MakerDao and Aragon.
777 standard.
Working a lot on an identity project.
", "keywords": [ "dao", "liquid", "status", "ico", "aragon", "gas_cost", "dappnode", "identity", "makerdao", "blockchain", "smart_contract", "giveth", "contract", "trustless" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
I’m a bit skeptical of formal verification stuff, but I think it’s important to keep pushing it forward.
Do more audits.
Write defensive code. Don’t try to do crazy things.
For the first time, we’re mixing two things that haven’t been mixed together:
The two:
Critical code – contracts holds money.
Open-source – everyone can see how it works.
E.g. you don’t have this in planes – critical program but not open-source.
E.g. in a website – it could be open-source but not critical.
So you realize you need to write perfect code, but that’s not possible. Because code is written by humans.
It’s important to improve:
Do not take risks.
Try 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.
Minimize the box, with its known security vectors.
On one side, you have a blockchain that by definition that is immutable. On the other side, immutable is not compatible with making mistakes.
Humans make mistakes. We are building things on top of that immutable base that could have mistakes.
But we need to keep blockchains immutable, because if don’t, we lose their power.
How do we solve this?
Possible 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).
E.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.
And then you can build the smart contract applications on this second layer.
Want to make decentralization linear; so you don’t have to take the risks from the beginning.
All contracts in Giveth have escape hatches built in.
STANDARD 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.
Better compilers. Better testers. Better formal verification. All the tooling helps.
There are some errors that are not due to programming – they’re conceptual, due to economics, etc.
", "keywords": [ "dao", "tester", "ico", "library", "risk", "open_source", "contract", "economic", "governance", "decentralize", "multisig", "aragon", "compiler", "escape_hatch", "isolate", "smart_contract", "zeppelin", "tooling", "error", "mistake", "giveth", "hack", "security", "formal_verification", "blockchain" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "34": { "name": "Stefan George", "who_what": { "question": "Who are you and what are you working on?", "answer": "CTO of Gnosis and is building a prediction market, ddex and smart contract wallets.
Started in 2013 - discovered that we could add prediction markets using btc escrow because that was missing (a p2p marketplace for predictions).
Joe 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
Decentralized exchanges!! But not efficient on Ethereum today (scalability and number of participants). We have had to contribute to building the DDEX infrastructure.
Prediction 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.
DDEX 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).
Dutch exchange implemented on chain to solve front running problems.
Integrating 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.
Make sure that things like ETHPM are deployed across all test networks.
Also 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.
", "keywords": [ "payment", "contract", "ddex", "consensus", "wallet", "network", "ethereum", "gnosis", "deploy", "test", "ethpm", "token", "escrow", "smart_contract", "platform", "decentralized", "infrastructure", "maker" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "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!!
Just waiting for the Ethereum Query Language ;) :p
", "keywords": [ "ethereum", "incentive", "bounty", "query" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "35": { "name": "Alex Leverington", "who_what": { "question": "Who are you and what are you working on?", "answer": "Can’t say what I’ve working on in a concrete way, but I am building a team and starting a new project.
I’m advising some projects.
Did some original stuff on the P2P system.
", "keywords": [] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "Haven’t come across any tools for game-theoretical stuff.
For code: using scripts for testing.
Ideally 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.
It’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].
Will be looking at tools in the next two weeks.
Having a tool which exposes the EVM state – for this you need some code that understands how Solidity stores data in the EVM.
For looking at EVM state:
Remix is ok.
Aleph0?! Doesn’t exist any more.
Some cases where your code doesn’t change, but the environment around your code changes –– having actual tests.
", "keywords": [ "evm", "solidity", "remix", "execute", "test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
What we have right now for audits can be improved upon with better tools.
Audits and testing framework go hand in hand.
Auditor should be able to write a test to demonstrate the problem at the EVM level.
Instead of the auditor suggesting some workaround or wrapper.
Or auditor provides proof for something that works well.
", "keywords": [ "evm", "issue", "security", "test", "wrapper", "open" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "36": { "name": "Alex Miller", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
The problem here is sourcing a centralized repository for information[a][b].
EF website doesn’t do that.
Wouldn’t know where to point people from intro documentation.
Truffle & Solidity have good docs e.g.
", "keywords": [ "truffle", "documentation", "solidity" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle
Configure parity instance https://github.com/GridPlus/trustless-relay/blob/master/parity/boot.js
Infrastructure tool to spin up local instances of Parity or Geth
", "keywords": [ "js", "parity", "truffle", "infrastructure", "trustless" ] }, "testing": { "question": "How do you handle testing?", "answer": "Use Mocha; plain old truffle tests.
I don’t do contract unit tests.
", "keywords": [ "unit_test", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Hasn’t had any novel code that needed security audits before
There are common patterns that could be detected. E.g. reentrancy attacks, etc
", "keywords": [ "reentrancy" ] }, "bounties": { "question": "Other bounties?", "answer": "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.
People should be using websocket calls more. Maybe more education around this. Serious efficiency gains to be had here.
", "keywords": [ "event", "websocket" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "37": { "name": "Dave Appleton", "who_what": { "question": "Who are you and what are you working on?", "answer": "Lead blockchain dev @ HelloGold.
Token backed by gold.
Does consulting as well – writing smart contracts & backend for blockchain projects
", "keywords": [ "blockchain", "hellogold", "contract", "token" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Helps that I’ve been coding for a helluva long time.
The hardest thing for new devs is getting to contact the people they need.
It’s also hard to find non-expensive auditors.
Gitter community is the key
Best dev communities or Gitter channels:
Go-ethereum
Solidity
Parity
I go to the specific one I need at the time.
", "keywords": [ "community", "ethereum", "solidity", "parity" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "38": { "name": "Peter Kieltyka", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
One 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.
Love building new models on blockchain. What is most excited to do is to create utility through video games via blockchain.
", "keywords": [ "game", "scalable", "cost", "fair", "blockchain", "decentralized" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "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.
Game is offchain, persist the awards on chain. Based on a finite state design.
Use Truffle, Ganache-cli, write the infrastructure in Go. Geth is written in Go, that’s very nice.
Client side application, standardize on Ethers.js (Richard Moore). Without Metamask you lack adoption. Ethers.js is being ported to Typescript, excited about that!
Web3.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.
Truffle 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.
", "keywords": [ "contract", "testrpc", "ico", "deployment", "developer", "client", "typescript", "state_channel", "design", "dependency", "truffle", "open_source", "token", "ganache", "blockchain", "metamask", "knowledge", "geth", "infrastructure", "api" ] }, "testing": { "question": "How do you handle testing?", "answer": "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
", "keywords": [ "mocha", "ide", "chai", "solidity", "typescript", "test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
", "keywords": [ "network", "formal_verification" ] }, "bounties": { "question": "Other bounties?", "answer": "Gas profiler 100%.
Would 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.
", "keywords": [ "ethereum", "js", "vm", "gas" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Profiler at ETHDenver, to see gas costs.
eWasm will be game changing. Potential for having other languages target the EVM will create a more productive developer experience.
Vyper will be great. Their goals are twofold, improved security through usage of the language. Learning from Solidity. Security + productivity.
Really happy with seeing progression of Solidity. As cool as ewasm is, who knows when it will be ready.
", "keywords": [ "evm", "ewasm", "developer", "solidity", "security", "cost", "vyper" ] } }, "39": { "name": "James Prestwich", "who_what": { "question": "Who are you and what are you working on?", "answer": "Simple contracts to manage cross-chain swaps and contracts.
", "keywords": [ "contract", "swap" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Python ETH Library - ABI Parsing expects events to be in two different formats neither of which you expect - ecosystem standardizes on hex strings
RLP is a hot mess - why use a non-standard serialization format for everything
Ensures nobody understands what’s going on and things aren’t readable - serialization format for everything ETH - includes transaction data
As a human - can’t reason very well about those blobs or what those structures will have
Developing contracts on Bitcoin first - Solidity, Script, Snark tidbits, IVY (compiles to bitcoin script)
", "keywords": [ "event", "solidity", "contract", "library" ] }, "testing": { "question": "How do you handle testing?", "answer": "Wrote tests with James on Integral stuff
", "keywords": [ "test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "40": { "name": "João Gabriel Carvalho", "who_what": { "question": "Who are you and what are you working on?", "answer": "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!
", "keywords": [ "aragon", "developer", "openzeppelin", "audit", "solidify", "smart_contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle.
Used a little bit of Embark but not a ton.
Use Mythril, Remix, TestRPC -> Ganache, Geth, also used a few Solidity flatteners.
Infura.
Web3.js.
", "keywords": [ "embark", "infura", "solidity", "remix", "truffle", "geth" ] }, "testing": { "question": "How do you handle testing?", "answer": "Do it manually, 1000 accounts with 1000 Ether. A big loop and keep sending transactions
Do this multiple times with multiple states. A lot of handwork for not a lot of results.
Large scale testing is not really worth it.
Was 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.
", "keywords": [ "transaction", "test", "ico" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
For Auditing, use a lot of Remix with manual testing as opposed to JavaScript tests. This is easier and less fake.
The 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.
", "keywords": [ "external_audit", "oyente", "mythril", "developer", "javascript", "remix", "test", "openzeppelin" ] }, "bounties": { "question": "Other bounties?", "answer": "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.
", "keywords": [ "ide", "gas", "deployment", "remix", "good_ide", "deploy", "truffle", "geth" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
Lacking 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.
", "keywords": [ "infura", "solidity", "resource", "geth", "tx" ] } }, "41": { "name": "Andreas Wallendahl", "who_what": { "question": "Who are you and what are you working on?", "answer": "Kauri
Decentralized knowledge base built on Ethereum and IPFS
Github 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.
Most popular tutorial is new content from Maker.
", "keywords": [ "tutorial", "ipfs", "bounty", "ethereum", "github", "knowledge", "token", "maker", "decentralized", "kauri" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle
Geth nodes on Google Cloud
Eth.js
React
", "keywords": [ "react" ] }, "testing": { "question": "How do you handle testing?", "answer": "Needs to ask teammate (Josh Cassidy)
", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Also Josh Cassidy
", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "In-browser signing. Would make new user onboarding much, much easier. Metamask works on it but a bounty might drive it through.
A lot of people have built interaction with IPFS, that’s why we built IPFS-store and eventium.
Blockchaimulator for testing that runs through 100,000 blocks, somewhat instantly. We had to wait for blocks to be produced.
", "keywords": [ "onboarding", "ipfs", "bounty", "browser", "metamask" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Simple spin up of side-chain or scaling solution kind of like Heroku
Spankcard for counterfactual state channels is a good attempt at this
Omisego and Plasma team
Rapidly spin up and set criteria for Plasma chain
Gas costs
In 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.
", "keywords": [ "counterfactual", "gas_cost", "heroku", "state_channel", "plasma" ] } }, "42": { "name": "Clement Lesaege and Nico Wagner", "who_what": { "question": "Who are you and what are you working on?", "answer": "Working on dispute resolution through smart contracts
Arbitration - process to decide who is right/wrong. Looks more like an arbitration DAO - system of incentives.
Enforcement
Decision-making
Incentivising people
", "keywords": [ "dao", "arbitration", "decision", "incentive", "smart_contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Smart contracts - Remix
Being able to copy address directly is really cool now.
Stopped using remix core because writing tests in truffle is actually quicker than clicking everywhere through the `remix IDE.
Solidity - 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.
Byte manipulation is really needed in Solidity.
Add a solidity linter to Remix (already exists in Atom at least, but would be nice for having a properly integrated environment).
We really need a light client to use a DApp on a smartphone.
Truffle to run tests
Relying 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.
Better 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.
Truffle 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.
No warnings for deprecation!!
Frontend - 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.
Ethers.js is not well-known and it would be better to standardise things and have a common library for everyone to use.
Main issue with web3 lies in callbacks. They don’t use promises because the 1.0 version does not support them well.
", "keywords": [ "gas", "library", "atom", "engineer", "solc", "developer", "api", "solidity", "remix", "issue", "test", "redux", "truffle", "smart_contract", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
", "keywords": [ "network", "developer", "security", "fuzz", "test", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "A tool to analyse security of smart contracts better, especially complex smart contract suites. Very excited to see formal verification, whenever that comes out.
Fuzz testing is super important!!
Great to use truffle boxes, but all of them are unstable and not well maintained. Would be great to see more effort put in there.
Trying 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.
Not open source currently.
", "keywords": [ "protocol", "transaction", "client", "security", "ethereum", "open_source", "formal_verification", "smart_contract" ] } }, "43": { "name": "Dan Tsui", "who_what": { "question": "Who are you and what are you working on?", "answer": "LLC that does consulting and builds projects
Their first crypto client was Metamask.
Other examples: build UI on top of the smart contracts; how to integrate with scaling solutions.
Working with state channels on wallet. Should be live on 1st or 2nd week of April
First: “productionizing” their library for micro payments.
Got into this space contributing to the EthereumJS ecosystem.
Within the team, I function as PM and do code reviews.
", "keywords": [ "payment", "ui", "library", "wallet", "client", "ethereumj", "crypto", "state_channel", "scale", "pm", "smart_contract", "metamask" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "44": { "name": "Jacky & Matthew", "who_what": { "question": "Who are you and what are you working on?", "answer": "Matthew:
Cofounder of Kyokan, CTO
Client work
Plasma and Plasma Chain.
State channels work with Spankchain.
Infrastructural work + Solidity.
Jacky:
Cofounder of Kyokan
Building / integrating with Ethereum wallets
Solidity
", "keywords": [ "wallet", "spankchain", "client", "solidity", "ethereum", "plasma" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Matthew:
Working on plasma and writing it in Go. Focussed on interoperability between Geth and smart contracts.
My development style:
I really like Java. – enterprise-y tools make me productive.
IDE could be really improved.
I use IntelliJ’s Solidity plugin to edit Solidity.
“Jump-to-def”; “jump-to-implementation”; syntax highlighting
Big difference in productivity.
E.g. when I’m writing Go code, I can jump to the Geth definition. This is amazing.
I’m switching between Solidity / Go, or Solidity / Javascript
Solidity Javascript bindings through Truffle are good.
Integrating libraries designed for cryptocurrencies with front-end apps is hard:
Bundle sizing: different behavior if you’re running in the browser or in the backend.
E.g. if you compile a contract with truffle, you get a JSON file – which has the bytecode and all this stuff beyond the ABI.
This is heavy and unused.
Crypto.js has unnecessary dependencies:
Eth.js includes an ASN.1 parser which parses digital certificates –– which isn’t needed for any crypto.js uses.
Google Chrome places a size limit (3 MB) on service workers in Incognito mode.
Bundle sizing is important – need to take out dependencies.
Standardize the interfaces for all these libraries.
E.g. a standardize library to read BIP39 seed words – across different programming languages.
Is there a Javascript API to boot a testnet, deploy contracts, and run tests against it?
For running application tests –
I want integration tests that run against Truffle easily
Having the ability to do this via Javascript is important
E.g. automate this: https://github.com/machinomy/machinomy/blob/master/run_integration_tests.sh
People don’t know how to productionize a geth node:
On Ubuntu: you can ‘apt-get install geth’
Now, how do you secure it, monitor it, etc?
People say: “just use Infura” – but then you’re tied to Infura.
Some ideas:
Docker instances; Chef or Ansible scripts; that setup a Geth node which has a bunch of best practices around it.
As an example:
Your RPC port shouldn’t be open to the external world, but should be accessible to the front-end.
You need a layer sitting between the geth node and the external world, and gives: 1) analytics, 2) authentication, and 3) audit logging.
The dashboard could configure geth on the fly.
How do you secure a geth node with an RPC port:
Need only certain keys to be allowed to interact with it
Jacky:
Integrating Metamask with Dapps
Building a new wallet for Spank;
It’s a service worker
Three threads running at once:
Runs a bunch of background processes
The Wallet
The Dapp itself
The messaging between these three threads sucks.
Cross-window JSON RPC library.
Wallets are pushing the limits of what Chrome is capable of.
They’ve had to file two bugs with Chrome in the last month.
Runs into the service worker size limit.
Mostly Javascript and Web3 work
Lot of code repetition in loading state and confirming transactions
Web3 is kinda hard to use – large ABIs
Biggest problem has been around event management.
Key management is not that complicated – Web3 has a good handle on it.
The Web 3 interaction with the wallet:
Web3 provider talks to the blockchain –
Spank and Metamask – the provider is an instance of the ZeroClientProvider – written by the Metamask team
The ZeroClient makes all calls when there’s no key needed. When a key is needed, it calls into your codebase.
Biggest problem is around the communication of gas costs.
The UX around this.
Users pick really high or low gas costs.
There are better ways to estimate gas.
Would be nice: currency conversion utility tools.
Existing tools are pretty buggy.
ETH has many different units.
Units conversion.
Matthew:
I write all my own methods – other than lowdash where I pull specific utils out.
React / Redux.
Need a way of shoving Web3 stuff into your Redux state.
Managing the lock state of your wallet
E.g. you need the lock-state of the wallet, because the UI changes.
They written a util that queries the wallet, gets it’s lock-state, and puts it into the Redux state.
Authentication: people have public/private keypair; use this data as login.
Having a canonical way to npm install and have authentication build off of Metamask.
Nice to haves:
Typescript typing for crypto libraries.
Postgres types to manage Ethereum stuff –– addresses, wei,
Have these methods: .toFinney
", "keywords": [ "query", "library", "typescript", "design", "metamask", "api", "contract", "ui", "type", "wallet", "json_rpc", "dapp", "ethereum", "backend", "test", "zeroclient", "browser", "smart_contract", "gas", "javascript", "gas_cost", "solidity", "limit", "docker", "dependency", "testnet", "audit", "truffle", "open", "plasma", "geth", "analytic", "ide", "transaction", "event", "infura", "spank", "log", "blockchain", "syntax_highlight", "integration_test" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "45": { "name": "ANDREY PETROV", "who_what": { "question": "Who are you and what are you working on?", "answer": "https://thousandetherhomepage.com/
", "keywords": [] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle - not his favourite, but best thing out there right now
Vim for everything
Etherscan a lot
Remix IDE - trying this out sometimes, but also my own editor
Truffle
Also my own runner, written in go.
", "keywords": [ "truffle", "vim", "etherscan" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Write a lot of tests myself. Get other people to read it. Keep it as simple as I humanly can.
", "keywords": [ "test" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
", "keywords": [ "nodejs", "deploy", "integration", "solidity" ] } }, "46": { "name": "Liam Horne", "who_what": { "question": "Who are you and what are you working on?", "answer": "Co-founder of L4 and Counterfactual.
Two main things:
Leading 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.
Co-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.
", "keywords": [ "evm", "protocol", "event", "counterfactual", "dapp", "state_channel", "ethglobal" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle suite.
Highest 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.
Our whole framework is based around off-chain interactions, for which Truffle is not well suited.
The 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.
Would 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.
We did some of this, but it’s not well known and not the default across the ecosystem.
Use ethers.js a lot
ABI encoder v2
Not supported by truffle.
Ganache
Can be very unreliable for a lot of important things.
E.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.
However, the parity dev client doesn’t throw errors on revert, it just logs them, and there is no option to change this.
The fact that the behaviours are different between these two things is concerning and frustrating.
Parity and Geth
I 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.
Getting around all the configuration details is such a headache.
I just want to launch testnets, and even do so locally in a way that actually works in practice.
Anything to do with solidity at all really.
Libraries and tools
Remix
Playing with rust for its ability to write once, run everywhere.
Tonne of JS tools to quickly iterate
Typescript - 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.
", "keywords": [ "wasm", "library", "safe", "js", "network", "client", "solidity", "error", "heroku", "typescript", "deploy", "parity", "state_channel", "test", "testnet", "ganache", "browser", "truffle", "log", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "WASM is likely most useful for us medium term.
State 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.
We 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.
We 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.
Plasma and state channels require stripped and straight forward teams to work on this stuff that can build out all the tools we need.
Truebit is exciting.
", "keywords": [ "wasm", "safe", "ewasm", "js", "client", "state_channel", "concept", "browser", "plasma", "contract", "truebit" ] } }, "47": { "name": "RICHARD MOORE", "who_what": { "question": "Who are you and what are you working on?", "answer": "", "keywords": [] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "I use all my own stuff, mainly
Ethers.js
ethers.cli
Ethers.build
Parity
Node.js
", "keywords": [ "parity" ] }, "testing": { "question": "How do you handle testing?", "answer": "Automated testing? How do the facilitate manual testing?
Ethers.build
Automated
Also facilitates manual testing
Rudimentary debugging
", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Extensive testing!
Using ethers.build etc. code audits are usually from Yuet.
Usually just have someone else look it over.
More careful with blockchain-things esp once my money is in there.
", "keywords": [ "blockchain", "yuet" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Events!!
There’s definitely missing features of what ethereum actually stores in its DB.
I 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.
Would 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.
Events 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.
The 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...
[Greg is working on something that will do this]
", "keywords": [ "trace", "event", "infura", "en", "ethereum", "cost", "tx", "api" ] } }, "48": { "name": "James Childs-Maidment", "who_what": { "question": "Who are you and what are you working on?", "answer": "Been building social apps on Ethereum. Leeroy.
Storing all posts and likes on-chain, syncing that with a centralized database and frontend.
I started with some little smart contract that saved a string to variable.
After that, just dove in on making Leroy over the next few months.
After getting a feel for solidity by playing with Remix.
Didn’t really understand how expensive it would be to save everything on the blockchain. Solution was to store the hash of all the inputs.
From there, had to learn how to make things as cheap as possible.
Quite a bit of smart contract work on Leroy. Multiple versions of the contract along the way.
Because it’s as cheap as possible, Leroy doesn’t even fire events.
", "keywords": [ "event", "database", "solidity", "remix", "ethereum", "blockchain", "smart_contract", "contract", "leroy" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "React / Redux app, with a firebase backend
Truffle. Just deployed using Remix, and uses it for playing with the contracts in general.
If not already mentioned, are there any libraries you rely on regularly?
Web3JS
In a toy project, used MetaMask just for signing transactions. Had a separate web3 using Infura for other stuff.
", "keywords": [ "infura", "remix", "deploy", "backend", "truffle", "metamask", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "Truffle for testing (JS unit tests).
Really enjoying writing async await tests with Truffle.
Automated testing? How do you facilitate manual testing?
Play with the contracts in Remix. Deploy the contracts to testrpc and then test manually using the UI.
", "keywords": [ "ui", "testrpc", "deploy", "test", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "No process, but would love to have it.
Apart from testing, would be cool to have tools that analyze what you’ve written and make sure you’re not doing anything dumb.
Right now, using Remix is helpful for getting warnings and stuff.
Hasn’t used Oyente
", "keywords": [ "oyente", "test", "remix" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "When you use Web3 library with Metamask, it’s really crappy getting events coming through.
Maybe will get fixed when moving to websockets with 1.0
", "keywords": [ "event", "metamask", "websocket", "library" ] } }, "49": { "name": "Yondon Fu", "who_what": { "question": "Who are you and what are you working on?", "answer": "Previously: working on smart contracts.
Truffle, testrpc / ganache-cli.
Expanded our test suite so they could run on multiple clients: could point at testrpc, at geth or Parity on PoA mode.
Now: Golang for our node.
Integrating our smart contracts with their node that does video-processing.
Working with Geth. There’s packages for interacting with EVM.
", "keywords": [ "evm", "testrpc", "client", "test", "video", "truffle", "smart_contract", "geth", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "50": { "name": "Eric", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
One 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%.
Started 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.
", "keywords": [ "payment", "protocol", "transaction", "crypto", "ethereum", "infrastructure", "video", "decentralized", "steemit" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "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.
Delegated proof-of-stake system for electing service providers in the network. All built in Solidity, use Truffle for this.
Use some Trail of Bits for security stuff
Use IPFS for storage
Truebit for decentralized computation verification
Collaborate with Swarm team for video distributions
The 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.
", "keywords": [ "swarm", "protocol", "network", "solidity", "security", "ethereum", "video", "geth", "decentralized", "truebit" ] }, "testing": { "question": "How do you handle testing?", "answer": "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.
", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Internal security audits. Taking time to do thorough code reviews.
Trail of Bits did a security audit
Launch 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.
", "keywords": [ "community", "test", "assumption" ] }, "bounties": { "question": "Other bounties?", "answer": "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
Reputation 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.
Truebit 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
", "keywords": [ "protocol", "truebit", "ens", "identity" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Better Debugger comes to mind. Monitoring systems and alerting systems. Metrics gathering systems. No one has figured a great solution for this.
Where 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.
Transaction 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
", "keywords": [ "phishing", "protocol", "ipfs", "dapp", "research", "smart_contract", "platform", "decentralized" ] } }, "51": { "name": "James Duffy", "who_what": { "question": "Who are you and what are you working on?", "answer": "Hybrid online marketing + developer
Invested 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
My co-founder Luke was working as lead developer at crypto company called Block Mason
I 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.
The 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.
Digital Ocean style way to spin up ETH-based blockchains.
To 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.
Need developers building on platform - so built CryptoZombies
First, 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.)
", "keywords": [ "ui", "evm", "ide", "issue", "developer", "solidity", "crypto", "ethfiddle", "remix", "ethereum", "blockchain", "platform", "cryptozombie", "ethdeploy" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "Truffle / Ganache. When it’s time to test on a real network, sometimes just deployed to mainnet .
In-House guy out of NYC that does contract audits
Open Zeppelin stuff is awesome
Use own ETHFiddle to hack on code in the browser and share things with other people
Compiler output not good: just does a diff check.
Tried embedding Solidity Compiler, but errors weren’t descriptive enough
", "keywords": [ "zeppelin", "compiler", "network", "hack", "solidity", "ethfiddle", "error", "deploy", "ganache", "browser", "truffle", "open", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Some type of tool that would take ETH Smart contracts, pack them up and automatically deploy them to mainnet.
Heroku style CLI deployment tool or in-browser version.
Making deployment easier for testing and production.
Solidity is really “bare bones”
Hard to manipulate strings -- not present in Solidity
When trying to give examples in CryptoZombies -- couldn’t do much
Comparing strings -- no substring function
Would be nice to have more “Utils”
Started Solidity X
Superset of Solidity that compiles to Solidity (intelligent defaults and prevents security issues)
Think coffee-script for Solidity -- plan to continue development in the future
", "keywords": [ "type", "production", "deployment", "issue", "solidity", "heroku", "security", "deploy", "browser", "smart_contract", "cryptozombie" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "52": { "name": "Matthew Di Ferrante", "who_what": { "question": "Who are you and what are you working on?", "answer": "Audits
Some clients have their own testnets. Or some chain state that needs to be initialized before you can run the code.
Smart contract dev –
Decentralized exchange project –
Testing 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
I wish these tools had a dev mode – where you can deterministically generate accounts
Geth & Truffle & etc should have a 1000 accounts that always show up as the first 1000 accounts.
E.g. for testing signatures.
There should be a templated test environment; that you can use across environments, installations, etc.
I find himself editing this a lot.
People often give me tests which have addresses hard-coded in. I then have to set it up again.
Consistency:
Getting projects to sync up; or a tool to initialize the setup for different projects.
Can use ganache or testrpc upto a certain point, but then, it doesn’t scale.
Something that takes one second to run in geth, takes 20-30s on ganache.
A tool that seeds the addresses, accounts – environment imaging.
", "keywords": [ "signature", "testrpc", "client", "deploy", "test", "testnet", "ganache", "truffle", "smart_contract", "geth", "decentralized_exchange" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "53": { "name": "Jenna Zenk, Travis Jacobs", "who_what": { "question": "Who are you and what are you working on?", "answer": "Decentralized asset management system. Smart contract that allows you to set up and manage digital assets.
Feature complete protocol going up to mainnet for short period of time for testing.
", "keywords": [ "smart_contract", "decentralized", "protocol" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Smart contract: Dapp by Dapphub. We manage packages with git modules. Includes Solidity compiler.
Subpackages delivered as git submodules i.e. safemath.
Used 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.
Parity.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.
Didn’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
Ethers.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.
", "keywords": [ "dapphub", "library", "blockchain", "js", "json_rpc", "wallet", "dapp", "error", "parity", "deploy", "ganache", "browser", "truffle", "smart_contract", "geth", "metamask", "contract", "stack" ] }, "testing": { "question": "How do you handle testing?", "answer": "Use Parity.js for deployment on test network
For testing- use Ava javascript framework
", "keywords": [ "parity", "js", "deployment", "javascript" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Continuous integration with tests and Oyente integration
Use Oyente.js - Melonport has sponsored the development of. Knows certain set of issues that have occured in smart contracts.
Regular 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.
Thinking about formal verification but costs associated with it is really high.
", "keywords": [ "oyente", "issue", "js", "bounty", "integration", "bug_bounty", "cost", "audit", "formal_verification", "solidify", "smart_contract", "integration_test" ] }, "bounties": { "question": "Other bounties?", "answer": "Javascript library and
Light client
", "keywords": [ "client" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Really good .js library, better standard. Our front-end would love to help with ideation/funding.
We 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.
", "keywords": [ "query", "library", "js", "client", "infura", "limit", "parity", "history", "community" ] } }, "54": { "name": "Aaron Kumavis", "who_what": { "question": "Who are you and what are you working on?", "answer": "Whymarrh: contracting in the space, working on Metamask UI, working at Kyokan.
Kumavis: co-founder of MetaMask.
wallet functionality;
not losing your private keys;
showing you what you’re signing, and what the side-effects of that are;
choosing a good gas price
Using Ethereum.js, Eth.js.
One thing we don’t do well – conveying on-chain errors that happen during tx execution.
Want to be able to go deeper.
Source map tooling. Here’s where it exactly went wrong.
Want: an API to get source maps for published contracts.
Source mapping tool already exists.
Give it the trace information. They can generate this themselves using the json rpc.
Find where it reverted.
Throw that into the source maps.
That’ll give you the original line it was on.
Could do more fancy analysis: find what values in the state are.
Not sure how useful this would be the average user.
", "keywords": [ "ui", "gas", "trace", "tooling", "api", "wallet", "js", "json_rpc", "private_key", "error", "tx", "analysis", "ethereum", "contract", "metamask", "kyokan" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "We’ve had good experience with bounties – Gitcoin,
One issue: bounties denominated in ETH or tokens, which leaves them open to volatility and potentially unhappy contributors.
Gitcoin, has ERC20 support, so you can use DAI now, which should help significantly.
People 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.
Internally 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.
", "keywords": [ "issue", "bounty", "gitcoin", "token", "open", "spec" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "55": { "name": "Dan Finlay", "who_what": { "question": "Who are you and what are you working on?", "answer": "User interface platform apps - Apps that enable other apps.
A few gateway apps.
First layer of education making it easier for users to interact with other apps.
I started with the original “Hello, World” Greeter contract from ethereum.org.
I liked it so much I forked it.
Originally they had 3 tutorials: Greeter, Voting, and Crowd-funding - would be great to see that kept more up-to-date...
", "keywords": [ "tutorial", "platform", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "React, gulp, javascript, browserify.
Mocha for testing, build live reloading.
web3 api and rpc api.
sinon mocks.
Create a UI for smart contracts, run testrpc, deploy contracts, and query it.
If not already mentioned, are there any libraries you rely on regularly?
web3, eth-js, provider engine deprecating for json rpc engine, react.
bip-39, web crypto libraries.
Currently developing eth-keyring-controller
", "keywords": [ "ui", "mocha", "query", "testrpc", "json_rpc", "javascript", "rpc", "smart_contract", "api", "react" ] }, "testing": { "question": "How do you handle testing?", "answer": "Test network, mainchain, local test rpc, mocked user interface.
", "keywords": [ "rpc", "test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Regularly TDD. Write a lot of tests. Truffle, dapphub etc.
eth-js or web3 to deploy contracts and write tests over to that.
Low-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.
On metamask we use tests and QA. Automated tests and user tests.
Understanding the blockchain in the first place.
What’s happening under the hood and why I would care.
A big challenge people hit the first time is reading from blockchain versus proposing a change.
", "keywords": [ "dapphub", "solc", "api", "blockchain", "js", "remix", "tdd", "deploy", "test", "truffle", "rpc", "wrapper", "metamask", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "https://ethereum-magicians.org/t/strange-loop-an-ethereum-governance-framework-proposal/268/24
There’s a road map that needs to be executed for this to work. If I had to guess, here’s how it might unfold:
A 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.
Once 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.
There 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.
If 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.
IMO, 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.
", "keywords": [ "governance", "decision", "client", "execute", "ethereum", "incentive", "community" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "The ability to make really lightweight user interfaces that subscribe to blockchain state.
Would prefer that json-rpc return promises.
json-rpc is unperformant, wish it was easier to contribute to.
", "keywords": [ "blockchain", "json_rpc", "subscribe" ] } }, "56": { "name": "Christopher Brown", "who_what": { "question": "Who are you and what are you working on?", "answer": "Full stack web dev, working in finance and some other industries. Started in Eth after reading WSJ after Frontiers release.
VM was interesting - run code in the blockchain is really interesting.
Modular.network - working on a hybrid solution with Blossom.
Several microservices in AWS that are coordinating with SCs on the blockchains - all that talk to a frontend dashboard
Token contracts
More extensive libraries now - we have an open source repository for ETH contracts.
Math
Token
Crowdsale
Array handlers
Linked lists handlers
Landed on Status repos first when looking at this stuff :)
Looking at zeppelin’s libraries and they didn’t seem as organised as other strong OSS libraries.
All about documentation!! Seemed lacking and this is the focus at modular.network.
Not deployed libraries you can link to.
Modular deploys on all networks and you can link to them specifically using delegatecall.
Take ERC20 - no reason to have 10000 Full implementations out there, just need contracts to hold their own storage and implement the right interface.
Bridging tech is most important for foreseeable future due to efficiency concerns on chain.
ETHPM required for graceful handling of libraries and packages, easily, securely etc. Really need to focus on that.
Have some thoughts about using on chain tests for upgradeability.
", "keywords": [ "finance", "zeppelin", "bridge", "library", "status", "network", "documentation", "vm", "deploy", "ethpm", "open_source", "token", "test", "blockchain", "upgradeability", "crowdsale", "contract", "stack" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle for building, testing and compiling
Can be sketchy on deployments, though this has improved recently. Built our own deployment script to get around it though.
Test, compiling and running are cool, but none of them are linked very well.
Being the devs of both ganache and truffle -putting the scripts together that would run the whole suite would be awesome.
Needs easier integration with CI tools.
Test scripts from zeppelin (in the sol libraries that pulls up testrpc, gives it a bunch of accounts and then executes whatever you have written).
Dive into lower level Ethereum libraries a lot - ethjs-utils especially.
You 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.
It’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..
One of their new implementations is a new multisig wallet, picking up some stuff from ERC 191, added some things to address security concerns.
None 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.
More attention around lower level components is useful as we mature.
Ethereumjs-tx, ethereumjs-wallet, solidity-sha3, to get identical hashes
Little bit more control to JS devs.
Web3 1 looks good
Biggest mistake: made it default installer when web3 v1-beta came out and this is a crucial error!!
But 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?
Necessary because everyone running full nodes is never gonna happen.
", "keywords": [ "ci", "testrpc", "library", "multisig", "deployment", "wallet", "js", "ethereumj", "solidity", "mistake", "execute", "ethereum", "security", "integration", "test", "error", "context", "community", "tx", "zeppelin" ] }, "testing": { "question": "How do you handle testing?", "answer": "Just Truffle for tests
Mocha for unit and functional tests. Use mocha across the whole application base.
Have run Mythril on some mission critical contracts
Was a pretty good experience
Stay away from monolithic code bases, iterate and test as regularly as possible!
Applies especially to smart contracts
Use event logging to debug contracts if possible
Getting invalid opcodes as feedback when your code doesn’t run is the single most frustrating thing in the world!
This has now improved a lot, which is awesome! Not just OOG errors in solidity anymore.
Finished 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)
SC dev is much more like traditional application dev, not web dev. Updates are months apart and very purposeful, bundle a bunch of things etc.
We like solidity, and most problems are related to VM not being as capable as people currently want.
There’s a language called Jelly with very purposeful functions that are then linked together to create compound functions.
Someone 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.
Room for optimisation with bytecode there.
", "keywords": [ "mocha", "solc", "mythril", "solidity", "error", "vm", "test", "blockchain", "smart_contract", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "The community is doing a good job and a lot of the stuff we need is already being worked on by someone.
ETHDenver and the gas visualisation tool that came out of that.
Became 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.
More visual tools that you could wrap around smart contract code (that doesn’t get compiled).
Has 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.
Having 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.
Think 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.
Or, 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).
", "keywords": [ "library", "issue", "solidity", "error", "parity", "context", "access", "community", "smart_contract", "wrapper", "contract" ] } }, "57": { "name": "Harry Denley", "who_what": { "question": "Who are you and what are you working on?", "answer": "EAL: Ethereum Address Lookup to prevent phishing.
Back in June: chrome extension as a mini block explorer. Hover over any address, shows how many transactions it has etc.
Couple weeks later, dedicated himself to finding phishing sites and black-listing them with Metamask and his chrome extension.
Recently – added service every midnight to do data gathering on each domain.
There is a group working on anti-phishing. We share information and data through an established channel.
We now have a bot to run ops on domains (whois data gathering, DNS records, SSL dumps, Shodan data on the server)
We have also deployed an archive bot on Twitter @EthereumBadList
My main effort: to protect users.
In the start of 2017, I got into Ethereum development.
Met team at Myetherwallet (now MyCrypto). Introduced me to other people like Griff.
", "keywords": [ "mycrypto", "myetherwallet", "transaction", "bot", "eal", "ethereum", "deploy", "phish", "metamask" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Building a platform / website to educate people on how to stay safe. MyCrypto has some stuff.
I have a Twitter poll that described this idea.
Create a bounty around this.
", "keywords": [ "safe", "mycrypto", "platform", "bounty" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "58": { "name": "Taylor Monahan", "who_what": { "question": "Who are you and what are you working on?", "answer": "Chaos. 2017 in one word.
Started off as a fun side project –– cofounder is Kosla – they were both working part-time.
Then 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.
Ecosystem started going crazy –– she started leaning in.
Team 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.
Growing a remote crypto team. How to incentivize them & keep them happy. Raises don’t work in this space.
", "keywords": [ "security", "ethereum", "crypto", "mew" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Money is not their constraining resource. People, hiring, management are constraining.
Best thing for ecosystem right now is: educational, marketing, videos, tutorials, write-ups, explaining how things work.
E.g. when your mother hears about an ICO, and they google it, there’s good resources available to educate them.
In the beginning, MEW was a stepping stone for people who already owned cryptocurrencies, before they started using geth or parity or etc.
Now, this is no longer the case, there’s new people who don’t know anything about cryptocurrencies at all..
Biggest phishing attacks they’re seeing are airdrop sites. “Free money??” Typing your private key is not a good idea.
How does a project responsible onboard people onto Ethereum?
How does the experience look as dApps become more of a thing? How do people use this?
In a dApp, the wallet functionality should be completely abstracted away. The user shouldn’t even know that there is a wallet.
If I had extra money, I would give 100% of it to educational resources, people designing infographics, videos, etc.
", "keywords": [ "type", "explain", "ico", "tutorial", "wallet", "private_key", "resource", "airdrop", "onboard", "parity", "ethereum", "dapp", "design", "mew", "video", "geth", "phish", "infographic" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "59": { "name": "Nate Murray", "who_what": { "question": "Who are you and what are you working on?", "answer": "I started by creating my own token using the tutorial on Ethereum.org.
I also did some of the other tutorials on the Ethereum.org page.
Rich user-facing Dapps using a modern JS web tech stack.
Solidity for writing smart contracts and web3 for the connection to the blockchain.
Next thing I'm working on: solidity, truffle, javascript, ipfs.
", "keywords": [ "tutorial", "js", "javascript", "ipfs", "solidity", "dapp", "truffle", "token", "blockchain", "contract", "stack" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "I use python for numeric analytics (not really around dapps).
For desktop apps I'll use Electron.
For contract development I use solidity, and web3.js for a connection to the blockchain.
Zeppelin's libraries for solidity.
0x has excellent repo for js.
", "keywords": [ "analytic", "js", "solidity", "dapp", "blockchain" ] }, "testing": { "question": "How do you handle testing?", "answer": "At first, getting contract working use Remix or testing framework built into truffle.
I don't use Ganache.
I really like connecting my contracts a real instance, and I like using console to connect to node.
I do it in layers. First start developing against testrpc because its faster. Then use geth.
", "keywords": [ "testrpc", "ganache", "truffle", "geth", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
Use solc linter when developing.
", "keywords": [ "linter", "solc" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Logging within solidity is hard, you can emit an event.
Tools around gas are hard, its so opaque.
Remix and gas is maddening, different gas limits, might have contract call that works in one env that doesn't work in another.
Formal verification; we need something better than solidity. Bamboo seems cool.
interested in the successor to serpent - vyper.
", "keywords": [ "gas", "event", "serpent", "solidity", "remix", "limit", "log", "formal_verification", "vyper", "contract", "bamboo" ] } }, "60": { "name": "Benjamin Bollen & Paruyr Gevorgyan", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
We have to be very pragmatic. 3 core regions to be make technology accessible by millions:
Management for users and development
Define a token for an application, how would you use it for your company?
Being pragmatic about scaling, a Layer 2 Solution. Not really sidechains, all value is only defined as value of ERC20.
Circumvent boundary of the bridge with a business solution.
We 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.
Had a bad experience with Ethereum Permission Client, had some incompatibilities on ABI level so had to do their own tooling.
", "keywords": [ "bridge", "tooling", "developer", "permission", "client", "ethereum", "scale", "token", "blockchain", "sidechain" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "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.
Web3.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.
OpenOSTBase- 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 :)
Web3.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.
What tools don’t exist at the moment?
Haven’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.
Biggest 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.
Clear explanation in Documentation.
General level: a big proponent of multiple chain universes. In OST users only really interact with Ethereum mainnet, only have tooling directed towards one chain.
Solidity perspective, have a diagram based solution to see all the connections. Solidity codebase diagram module would be very compelling.
How do you handle smart contract verification and security?
Guiding 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.
Now 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.
They 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.
Compiler, assembly tools, and debug tools are all major points of interest. Could be interesting if Solidity compiles to wasm, then you have portability.
What was the hardest part about learning to develop with Ethereum?
To 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.
Solidity 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.
Hardest 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!
More 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.
What are you most excited about in the short term?
Getting OST to version 1.0 :) But beyond that most excited about ewasm. Also excited about Whisper and Swarm.
", "keywords": [ "deployment", "network", "remix", "ethpm", "openostbase", "access", "community", "contract", "type", "wasm", "protocol", "compiler", "wallet", "ethereum", "test", "websocket", "ganache", "smart_contract", "wrapper", "cryptozombie", "zeppelin", "gas", "tooling", "tutorial", "solidity", "documentation", "audit", "geth", "ide", "swarm", "production", "security", "deploy", "parity" ] }, "testing": { "question": "How do you handle testing?", "answer": "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.
One 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.
", "keywords": [ "truffle", "test", "testnet" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "61": { "name": "Fredrik Harrysson", "who_what": { "question": "Who are you and what are you working on?", "answer": "Been a core dev on Parity for a few months.
Making the Ethereum client itself nice to use by developers.
Also building a solidity parser and linter
Building some JS libraries for developers to actually write dapps
Talk about the enterprise company dapp -- how did we scope, what tools, etc
All at a proof-of-concept stage. Probably 10 years before they can actually make it work in their business.
I set up the docker containers for the nodes, did the documentation, and built the React App
", "keywords": [ "library", "js", "developer", "solidity", "dapp", "parity", "documentation", "linter", "react" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Everything, even in dev environment is containerized
IPFS, React, Parity, ParityJS
Have some internal tools that generate javascript ABI’s from the smart contract spec
Have an internal CLI for deployment
Deploys the contracts and then initializes some values
If you change your contract in development, re-running this tool takes a super long time, which is frustrating
If not already mentioned, are there any libraries you rely on regularly?
Main library they use for all dapp development is ParityJS, and their new library called Bonds/007 (React integrations)
Parity Ethereum node has pub/sub now
", "keywords": [ "spec", "deployment", "javascript", "ipfs", "parity", "deploy", "integration", "parityjs", "ethereum", "smart_contract", "contract", "react" ] }, "testing": { "question": "How do you handle testing?", "answer": "Use truffle internally for testing some contracts
Also write own own testing tools using Rust because we don’t like javascript
", "keywords": [ "javascript", "test", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Internal audits.
We are introducing a checklist system for deployments.
Pre-, during, and post-deployment
Doing external audits on everything now. Even auditing Rust code right now.
External audits are great, but the average developer cannot afford that
***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)
", "keywords": [ "external_audit", "engineer", "checklist", "deployment", "developer", "documentation", "knowledge" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Setting initial values after deploying a contract is important
Being able to roll back transactions would be really nice for dapps
", "keywords": [ "deploy", "dapp", "transaction", "contract" ] } }, "62": { "name": "Nicolay Wolf", "who_what": { "question": "Who are you and what are you working on?", "answer": "Not developing lots of dApps.
Foundational work for WASM:
WASM interpreter
Runtime environment – which allows to run wasm within any network.
Forking Kovan – allowing wasm contracts to run
Running wasm on private chains
WASM interpreter:
Main problem:
Making the Rust interpreter deterministic.
WASM is not strictly deterministic –– need to narrow down to deterministic opcodes.
Need to ban several opcodes, e.g. floating points. Simple solution: just parse WASM and fail if there’s any floating point opcodes.
Other option: to canonicalize the NaN constant –– you need to bring all these flags under one definition.
One idea: you could check after each floating point opcode –– to see if its NaN and use canonical.
BUT this is not worth the effort, because no blockchains apps will have floating point anyway.
Other sources of determinism: deterministic stack for execution
WASM doesn’t enforce size of the stack ––
When you get to JIT compilation of WASM, this compiles into using a register-machine specific to the hardware architecture; this process is actually deterministic.
But it’s non-deterministic when you go to run it.
E.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.
This can fail at different times for different machines. So, it’s non-deterministic.
We’re transforming existing WASM into this modified WASM that takes care of these issues.
Any WASM implementation that takes untrusted code from the network needs to have this stuff done.
eWASM collaboration will be helpful ––
Mozilla has a Rust-WebAssembly group.
Gas metering – not challenging but needs to be done
We have tools which transform WASM from free-form to gas-metered form.
Includes how much opcodes cost.
eWASM has this also –– we’re taking a more scientific approach to this.
Parity simply uses the eWASM table.
Don’t need to be super precise, just need to protect against malicious users.
Memory also costs gas.
Simple way is to charge for memory linearly.
The 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.
Gas costs are embedded into the bytecode.
Proving the correctness of implementation
Fuzz testing against various interpreters – spec implementation;
Fuzz 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.
The interpreter should not panic in any case –– otherwise, malicious actor could crash certain nodes
They use cargo-fuzz for rust
There 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.
", "keywords": [ "wasm", "spec", "gas", "ewasm", "network", "gas_cost", "fuzzing", "dapp", "limit", "parity", "cost", "test", "blockchain", "kovan", "contract", "stack" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Research for cost of running WASM on different architectures and machines.
Scientific proofs on how this correlation works.
Or also computational analysis?
This will be used to assign costs to Opcodes, and also know exactly why.
Parity is using eWASM’s results for this currently.
", "keywords": [ "wasm", "ewasm", "analysis", "parity", "cost", "research" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "63": { "name": "Peter Czaban", "who_what": { "question": "Who are you and what are you working on?", "answer": "I started out building some trading algorithm.
During the early foundation days, there were workshops in London, and during one of those workshops I was writing a dapp using Mist.
Then, later, I deployed a token contract for fun, and then basically started straight away with client development.
Been working on the core Parity client on the consensus algorithms. Consensus contracts in solidity. Proof of stake.
", "keywords": [ "trading", "algorithm", "consensus", "token_contract", "client", "solidity", "dapp", "proof_stake", "deploy", "parity", "mist", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle, solidity syntax highlighter for VIM, Jupiter notebook for testing stuff
If not already mentioned, are there any libraries you rely on regularly?
EtherJS
In Rust similar libraries like @crypto and @key
", "keywords": [ "vim", "crypto" ] }, "testing": { "question": "How do you handle testing?", "answer": "Mostly truffle for testing. Also have some of my own custom tooling that works on RPC.
", "keywords": [ "rpc", "tooling" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "First contracts were usually for prototypes.
I would write contract, write tests, then integration tests.
Then would go through a review process.
Sometimes would go to an external audit.
This only happened for a few projects.
", "keywords": [ "external_audit", "contract", "integration_test" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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)
Parity / Truffle sometimes behave in different ways
Built a custom thing that had partial functionality to give a more consistent testing environment
Being able to track versioning of contracts from dev to deployment. Requires a lot of back and forth.
Pain points working with the language. I want a better type system!
", "keywords": [ "type", "deployment", "client", "parity", "versioning", "truffle", "contract" ] } }, "64": { "name": "Phil Castonguay", "who_what": { "question": "Who are you and what are you working on?", "answer": "Used to work for 0x, now I work as a SC dev and researcher independently.
I was the developer relations manager at 0x.
I am now focussing on state channels, signature-based improvements in general smart contracts, blockchain storage (utilising merkle trees and improving best practices).
Working with a gaming project that utilises state channels, unrelated to Raiden.
A 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).
Working 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.
Right now smart contracts don’t listen to each other and require 3rd parties to watch the chain and inform them.
", "keywords": [ "signature", "polymath", "developer", "gas_cost", "state_channel", "ethereum", "cost", "blockchain", "raiden", "smart_contract", "crowdsale" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Using Truffle, Ganache, testrpc
Most of the tests are not run in parallel, under-utilising my compute resources, can’t be adapted easily or extended.
Remix for quick prototyping
Actually 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.
Typescript (mostly for testing)
Mostly following 0x standards - transcribing from typescript to js that make it really easy to define statically-typed tests.
Mocha, chai
", "keywords": [ "type", "mocha", "chai", "testrpc", "js", "typescript", "resource", "remix", "test" ] }, "testing": { "question": "How do you handle testing?", "answer": "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.
Writes unit tests myself and try for 100% coverage.
I uses Mythril and am looking forward to formal verification.
Standards 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.
", "keywords": [ "fuzzing", "mythril", "fuzz", "test", "formal_verification", "unit_test", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Nothing exists for state channels regarding how you pass messages and other p2p tools that allow different agents to communicate easily with each other.
Not easy to document this.
No easy way to test how peers are interacting with each other and you want to run simulations in state channels.
Scheduled 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.
Easy to use and easy to test frameworks for this stuff is going to be super important.
Would 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.
Simulator 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!
Couldn’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!!
Very 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.
", "keywords": [ "signature", "type", "mycrypto", "library", "transaction", "analysis", "network", "gas_cost", "client", "remix", "state_channel", "ethereum", "research", "test", "dependency", "token", "truffle", "contract", "zeppelin" ] } }, "65": { "name": "Federico & Jaynti", "who_what": { "question": "Who are you and what are you working on?", "answer": "Trying to work on Plasma – white paper is unspecified; it is not clear yet.
Started Dagger project – to get events for our UI or backend.
Use cases:
If you want to send an email or notification to users.
If your multisig wallet has incoming or outgoing transaction.
UI for the front-end; a multisig wallet: sent a tx and see it real-time. Make UI/UX better in Ethereum.
", "keywords": [ "ui", "event", "dagger", "backend", "email", "tx" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "66": { "name": "Alex Leishman", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
Doing a lot of lightning stuff right now, payment channels. Spending a lot of time investing companies in the space, doing due diligence.
Been deeper into the bitcoin world, a bit of an outsider in Ethereum.
I built a blockchain analytics tool called blockseer for bitcoin and Ethereum
Taught Bitcoin/Ethereum class at Stanford in 2015
Am really proud of the exchange and brokerage that I built in Taiwan.
", "keywords": [ "payment", "analytic", "engineer", "polychain", "blockchain" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "I don’t do much eth-dev right now.
", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "CI pipeline needed.
Testing and security audits are one and the same since you’re deploying it once.
Few contracts are heavily audited, and ecosystem is built around those smart contracts.
", "keywords": [ "ci", "deploy", "audit", "smart_contract", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "We refer companies to trail of bits/ other.
Formal verification handled by specialized firms. Important contracts will/should be audited by people.
", "keywords": [ "contract", "audit", "formal_verification" ] }, "bounties": { "question": "Other bounties?", "answer": "Large players funding bug bounties for public smart contracts.
Multisig is a pain in Ethereum. Multiparty signature with a single key from an account.
", "keywords": [ "multisig", "ethereum", "smart_contract", "signature" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Native chain improvements
Casper
Generalized staking system where you can sell your stake via a new token via smart contracts. Bond for staking.
Programming tool chains for web assembly. Being able to take advantage of multiple languages like C++ and Rust and have it compiled down to WA.
LLVM - any LL language could compile to web assembly.
", "keywords": [ "smart_contract", "token" ] } }, "67": { "name": "JOHN PALMER", "who_what": { "question": "Who are you and what are you working on?", "answer": "Web applications that interact with smart contracts, usually through MetaMask or Infura.
We built www.hashheroes.com as our first dive into Ethereum.
We built www.withpragma.com to make Ethereum development easier.
We built www.onhexel.com to make it easier for anyone to experiment with tokens and try new ideas.
", "keywords": [ "smart_contract", "infura", "metamask", "token" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Web3.js
0x.js
Truffle
Testrpc
Infura
Remix Solidity
Etherscan
", "keywords": [ "js", "infura", "etherscan" ] }, "testing": { "question": "How do you handle testing?", "answer": "First of all, I write unit tests in javascript and run those locally.
Interact with smart contract through remix solidity or Pragma.
Test my app in my own UI. Check etherscan to make sure that happened.
", "keywords": [ "ui", "smart_contract", "test", "etherscan" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Linting
Code review on my own and with other people. Check best practices from Consensys
", "keywords": [ "code_review", "consensy", "lint" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "It’s not possible to bundle two different transactions together and pay with them at the same time with MetaMask.
I wish errors in contracts were surfaced better. Generally, it is hard to know when things go wrong in contracts[a].
Gas limit
Wish 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.
", "keywords": [ "gas", "transaction", "error", "limit", "execute", "metamask", "contract" ] } }, "68": { "name": "Marcus Molchany", "who_what": { "question": "Who are you and what are you working on?", "answer": "Made a few standalone contracts for fun.
More full-fledged projects are web frontend with blockchain backend.
Web apps use Metamask to interact with blockchain. Infura as provider if MetaMask not installed.
We built www.hashheroes.com as our first dive into Ethereum
", "keywords": [ "infura", "backend", "blockchain", "metamask", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Ethereum: Remix solidity, testrpc, truffle, web3 JS, Infura, Etherscan
Web: React / redux, create-react-app
", "keywords": [ "testrpc", "infura", "ethereum", "etherscan", "redux", "truffle", "react" ] }, "testing": { "question": "How do you handle testing?", "answer": "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.
When 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.
Automated testing?
Included above. Automated is unit tests with truffle. Manual is event logging, usually in Remix.
", "keywords": [ "testrpc", "event", "production", "javascript", "vm", "truffle", "unit_test", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Warning messages from Remix or solc.
Reading through Consensys best practices and making sure I use them in my contracts.
Asking for code review in subreddits.
", "keywords": [ "consensy", "solc", "subreddit", "remix", "code_review", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "I really want a richer debugger. The one in remix is too hard to figure out[a].
", "keywords": [ "remix" ] } }, "69": { "name": "Piper Merriam", "who_what": { "question": "Who are you and what are you working on?", "answer": "Trinity: new Python-based Ethereum node.
Py-EVM: python implementation of EVM in python.
Sharding & Casper research team are building on this.
Web3.py: python equivalent of web3.js
V4 is coming along nicely and is fairly solid right now.
Under the above – there are a myriad of base libraries that I’m the developer –– i.e. side-effects of the work.
Package management
Similar to Populus –– but actually the underlying core package-management structure. The solution is ready, it just needs to be built.
It is project that I had to cut off, but wants to pick up again –– immediately came to mind for bounties.
", "keywords": [ "library", "developer", "bounty", "trinity", "research" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "The Hive tests –
Framework that black-box tests EVM implementation.
Has had multiple conversations with cdetrio on Github.
Bounty: needs clear documentation: “for your EVM to be included in the Hive tests, you need this stuff.”
Maybe it’s not super high impact and not crisply defined
Bounty: need a formal spec for the Json RPC api.
Have integrations tests in Web 3. Subtle differences across nodes, which make things confusing.
Somebody needs to shepherd the ERC spec through –– most of the work is done. Dan Finlay already hammered out most of the work.
Someone needs to write the schema for all Json RPC endpoints.
This is super well defined.
", "keywords": [ "evm", "json_rpc", "bounty", "github", "documentation", "integration", "test", "api", "spec" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "70": { "name": "Richard Ma & Don Ho", "who_what": { "question": "Who are you and what are you working on?", "answer": "Focused on the security aspect of Ethereum. 3 main challenges for going mainstream:
1) security, 2) scalability, 3) usability.
Too many projects; audit talent is in low supply;
System to allow anyone to get a high-quality audit for teams.
Components:
Payment smart contract: deals w upgrades; governance
Verification node: software to verify smart contracts
Software library: formal verification, static analysis checks
", "keywords": [ "payment", "governance", "library", "static_analysis", "security", "ethereum", "audit", "formal_verification", "smart_contract", "usability" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "IDEs:
Remix is probably the best one. No support for quick-fixes (like you have in IDEs).
Better support for projects.
Manage dependencies.
Code coverage tools, to see how good your tests are. Integration would be good.
Existing tool: run this as a separate command & get results in a web ui.
Solidity-coverage.
Has some static analysis tools – more would be better.
Notes:
Web UI is weird. We don’t use it, because of lack of project support.
We use sublime text / IntelliJ.
Better syntax coloring like Remix would be good.
Bounty for solidity support in Vim and/or Sublime.
Debugging
Half the time is always spent debugging.
Debugging with truffle & node-js is horrible.
Have to debug the JS and contract parts separately.
Different environments.
We do iterative development; somewhat test-driven; We’re aiming for very good coverage.
What I’m envisioning: putting a breakpoint into the smart contract or Javascript. Ideally, one breakpoint can step through all code.
Testrpc
Usable blockchain explorer for testrpc – to explore local data.
Would be great for learning as well.
Streamlining code export for Etherscan verification during contract deployment
Typically, you have to flatten all your imported contracts, it’s a pain in the ass.
Would be good to have a place to do this. Assures that the version is consistent.
Sometimes you need update your contract –
Tools to evolve your old contract into your new one. Only deploy the additions.
We had this issue in their ICO: we wanted to change the end-date for the ICO.
There’s a valuable data in the old contract.
Could run into problems with consistency.
More than “library driven development”, would be good to have tools that generate this for you.
My vision: refactorings like in Eclipse; pick refactorings (e.g. can split the class, etc). This would tie into the IDE.
Developer education programs
Lesson plans. Get each company to do one session
We went to a meetup for people who like to learn Ethereum. It was way oversubscribed.
Could be good for recruiting / onboarding.
We’re putting together a “minimum security standard” after interviewing all auditing teams.
Existing auditing tools for Solidity are poor.
Read our Solidity analyzer: https://github.com/quantstamp/solidity-analyzer
", "keywords": [ "testrpc", "ico", "library", "js", "deployment", "integration", "code_coverage", "contract", "sublime", "onboarding", "bounty", "ethereum", "intellij", "test", "smart_contract", "vim", "javascript", "solidity", "recruiting", "github", "dependency", "etherscan", "truffle", "ide", "blockchain", "issue", "analysis", "developer", "security", "deploy", "quantstamp", "breakpoint" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "71": { "name": "Jay Rush", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
", "keywords": [ "ethereum", "blockchain", "quickblock", "decentralized", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "The tracing API across the two clients is different and seems ad-hoc.
A common format for the tracing RPC calls, so tools such as QuickBlocks which rely on the traces would be easier to build.
I use Parity. I can’t switch to Geth because they don’t share the same interface for the traces.
", "keywords": [ "trace", "client", "parity", "rpc", "geth", "quickblock", "api" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "72": { "name": "Yann Levreau", "who_what": { "question": "Who are you and what are you working on?", "answer": "Working on dev tools for the Foundation for the last 2 years.
Working on Remix for the last 1.5 years.
Working alone for the last bit.
Over the last 6 months, there are more developers. Team is 4-5 people now.
Iuri Matias: dev of Embark –– he’s on the Remix team.
Main scopes of work:
Improving the UX.
There’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.
UX for people to use Remix and deploy contracts, and not make mistakes.
Adding static analysis
There is a new tab-based layout.
There are several modules.
Splitting Remix into different modules
Can 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.
He 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.
Road is adding the static analysis.
", "keywords": [ "embark", "analysis", "developer", "static_analysis", "remix", "mistake", "deploy", "contract", "chat" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Focussed on Remix and improving the UX:
Remix is an entry point for users
But it’s hard to use for beginners.
It’s hard to use if you don’t know blockchain or the tech behind it.
There’s documentation and videos on youtube – still hard to use.
Idea: do UX user interviews
take 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,
They 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.
There are three kinds of blockchain users
1) front-end dev: wants to use the blockchain to build UI, but doesn’t care about contracts.
2) contract developer
3) administrator: not writing code, but still needs to call contracts or send transactions to them.
Remix is not focused on front-end devs right now. They’re not targeting these people. They target contract developers or admins who “use” contracts.
Is there a tutorial, or a beginner contract that it initializes:
Yes. There is a “ballot” contract – but it’s kinda opaque and hard to understand.
Docs: remix.readthedocs.io
Has a quick start page.
Need to improve: onboarding for “administrator” users (above). So they can use Remix without making errors.
Two bounties
User testing for various blockchain-user personas (above).
Making tutorials or videos for beginners using Remix.
Building the static analysis tab:
Need to add more modules.
There will be a way to add plugins in Remix
Let’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.
E.g. Solium integration.
We are architecting the plugin API with the Solium team.
Another example: Oyente –– we’re integrating it as a plugin.
Potential bounty in the future:
Writing good documentation around this. We’re all super busy devs, and need people to help with documentation.
Last 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.
", "keywords": [ "ui", "oyente", "api", "tutorial", "transaction", "onboarding", "developer", "static_analysis", "bounty", "remix", "error", "documentation", "github", "integration", "test", "video", "blockchain", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Hard to make links between tools.
If you want to make a DAPP (truffle and remix, metamask for front-end), how can you aggregate all tools or write documentation?
Swarm integration for Remix?
Currently if you “import”, it imports from the Swarm gateway –- it’s a basic integration, and can be improved to be really cool.
Frustrated developing on Swarm. Building Swarm integration, but not usable in production.
Was 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.
Swarm not in production environment yet -- looking forward to this.
Web3 library
In 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).
“Wrapper around Send Transaction Function”
Possible 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.
Contract’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).
Would require changes in solidity to provide this functionality to web3
", "keywords": [ "swarm", "evm", "trace", "safe", "production", "transaction", "solidity", "dapp", "remix", "execute", "documentation", "limit", "integration", "mistake", "swarm_integration", "truffle", "wrapper", "metamask", "contract" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "73": { "name": "Gustavo Guimarães", "who_what": { "question": "Who are you and what are you working on?", "answer": "Blockchain engineer, working in the space since 2016. Mostly as a freelancer, helping companies solve business problems using blockchains.
Middle 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.
Abstract idea from property to raffling all kinds of assets.
Smart contract developer in general.
", "keywords": [ "raffle", "protocol", "engineer", "developer", "blockchain", "smart_contract", "samsara" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Use Truffle heavily.
Still a long way away from good debugging tools.
Using Remix out of habit, especially to check and step through opcodes.
Remix to dig deeper into what is going on with my solidity code. Especially the debugger there to dive into the EVM.
Have got used to the debugger here, but it is still so obscure when something throws an exception and difficult to find out why.
I have developed some intuition for this, but it’s really, really difficult for people just beginning.
No break points!
Use open zeppelin as reference for smart contracts - have worked on some educational projects with the Zeppelin team.
No issues with this. Haven’t looked into zeppelin_os yet.
But the idea is quite interesting - upgradeability and on chain libraries are cool.
Truffle-flattener library - make all your modules into one file. Use this to deploy, rather than doing it file by file.
React for frontend stuff.
Web3 to hook it all together.
Websockets (wss) are tough to work with. Having difficulty connecting to them through the infura nodes.
Overall, really happy with the new version - it solves a lot of problems, particularly around signing transactions safely.
", "keywords": [ "evm", "library", "issue", "infura", "remix", "deploy", "upgradeability", "websocket", "truffle", "smart_contract", "zeppelin", "react" ] }, "testing": { "question": "How do you handle testing?", "answer": "I test in JS - unit tests mostly.
On 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.
Overall, quite happy with what comes out of the box with Truffle.
Have only added await async calls to make things easier to read. Have some Mocha extensions added for the same reason.
Prefer readable code, rather than fast code, especially when it comes to testing.
", "keywords": [ "mocha", "test", "truffle", "smart_contract", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Here in Berlin I have worked with solidity,berlin and they are amazing. Do really comprehensive audits.
Have also used formal verification tools: most often Mythril, sometimes Oyente.
I am also aware that the invariance checks etc. are also created by humans, so might not be entirely comprehensive.
3 levels of checks: write code, write tests for the code, pass to another engineer to check, then formal verification tools, lastly do the audit.
", "keywords": [ "oyente", "engineer", "mythril", "solidity", "formal_verification", "audit" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Would be nice to have a tool that could get bytecode and re-engineer it into solidity code.
Sometimes 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.
Open source block explorer.
", "keywords": [ "engineer", "solidity", "block_explorer", "deploy", "open_source", "contract" ] } }, "74": { "name": "Scott Wright", "who_what": { "question": "Who are you and what are you working on?", "answer": "Just simple stuff - proofs of concept.
Working through course material
Building a token and a very minor escrow app
Timed auction.
", "keywords": [ "course", "concept", "token", "escrow", "auction" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Remix
Geth obviously
SolC for compiling
Yarn is (apparently) standard now for js
If not already mentioned, are there any libraries you rely on regularly?
Web3
", "keywords": [ "js", "geth", "remix", "solc" ] }, "testing": { "question": "How do you handle testing?", "answer": "Automated testing?
There’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…
I WANT an automated test suite, but nothing out there right now.
", "keywords": [ "ui", "ide", "test_suite", "remix", "test", "testnet", "geth" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
A lot of uncertainty around how gas works.
What is it exactly, how does it get used, how do you optimize for it?
The basic idea is fine, but the details when you’re building stuff are very hard to find out
What are the best design patterns for dealing with it, the strategies?
Also, 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.
There’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.
Would 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.
", "keywords": [ "gas", "issue", "tdd", "design", "test", "knowledge", "open" ] } }, "75": { "name": "Felix Feng", "who_what": { "question": "Who are you and what are you working on?", "answer": "Founder of Set Protocol, wrote all the smart contract code/unit tests
Aims 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.
Just 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.
", "keywords": [ "protocol", "library", "javascript", "dapp", "test", "token", "smart_contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Internal javascript library in Typescript for UI interfacing with their protocol (bundle/unbundle)
Uses 0x ABI gen for automatically generating typed objects
Truffle for testing/ compiling
TruffleHD wallet provider repo
Infura for deploying code to Ropsten testnet, hitting services all the time. Easier to deploy to testnet.
For deploying to mainnet, they use Remix.
", "keywords": [ "ui", "type", "protocol", "library", "wallet", "javascript", "infura", "typescript", "deploy", "testnet" ] }, "testing": { "question": "How do you handle testing?", "answer": "Started with truffle tests
Then converted tests to typescript for type safety (avoids host of potential errors, useful for building FE library as well) and used 0x ABI gen
Aim for 100% test coverage (~95%)
", "keywords": [ "type", "library", "error", "typescript", "test", "safety" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Contracted security auditing firm before launching to mainnet and did it internally.
Introduced to firm through investors
Zeppelin and Consensys security etc. are super backlogged and can be highly expensive.
Tried automated tests for quantstamp but their compiler solidity version (4.2.3) wasn’t supported.
", "keywords": [ "investor", "compiler", "solidity", "security", "quantstamp", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "Debugger
More free automated formal verification
List i.e. Aggregated “Awesome Ethereum” for security (blog posts, tools, etc.)
", "keywords": [ "security", "ethereum", "formal_verification" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Debugger. Especially as contracts start linking to each other, stack trace gets more important.
Open source block explorer for any chain.
Lot more typescript tooling. 0x started the movement and built tooling around it.
People are building their own deployers/compilers. More standardization need here.
", "keywords": [ "trace", "tooling", "compiler", "typescript", "block_explorer", "open_source", "standardization", "contract", "stack" ] } }, "76": { "name": "Simon Jentzsch", "who_what": { "question": "Who are you and what are you working on?", "answer": "CTO of SlockIt.
Daily standups like any other startup, making sure all our tools work correctly
Part of day consists of update on new tools, libraries and their respective stability. Assessing trade-offs is difficult and time-consuming work.
Consulting work, experience with real customers
Connecting IOT devices to the blockchain
Energy Web foundation, smart meters
Smart contracts for data incoming from IOT
Determine what type of hardware they should use
Building universal sharing network (USN) in-house.
Connect IOT devices, access control, rental and sharing settings
Launched MVP on Testnet and inviting beta users. Planning on deploying to Mainnet.
Public repo containing architecture and contracts
All smart contracts will be publicly available after security audit
Use Kovan since its compatible with most clients. Also on Rinkeby.
Using Parity for tests, but interoperability between clients is lacking badly.
Gives and recieves audit
First, internal security audit
Then, number of experts from different teams.
", "keywords": [ "type", "library", "rinkeby", "network", "client", "deploy", "parity", "iot", "testnet", "test", "access", "blockchain", "slockit", "smart_contract", "audit", "kovan", "contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Start with Truffle - mainly for testing and setting up environment
Doesn’t produce/support typescript
Extended version we produced and use for
Typesafe contracts based on solidity contracts
Throws errors on incorrect smart contract types
Usually write tests with Travis CI, for all three browsers (GETH, TestRPC, Parity)
Use Remix for debugging
Wish we had a more stable and easier to use debugger!!
Test RPC vs Ganache
Many tiny differences (output syntax, JSON RPC error messages, etc.) between clients makes testing very hard between clients
RPC 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.
Not specific enough, too much room for divergence
Web3 library is trying to limit this
", "keywords": [ "type", "ci", "library", "json_rpc", "client", "typescript", "error", "travis", "limit", "test", "solidity_contract", "ganache", "browser", "truffle", "rpc", "smart_contract", "geth", "contract", "spec" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Scalability is long-hoped for and looked forward to ;)
Mainnet as main authority,. For different devices, different chains.
Current work around could be to use bridges (parity)
Micropayment, multiply party, state channel Solutions like Raiden up and coming, but not ready yet
Contracts that pay only for your devices from a certain account
They currently use libraries and packages to avoid security issues
", "keywords": [ "bridge", "library", "issue", "state_channel", "security", "parity", "raiden", "contract" ] } }, "77": { "name": "Fernando G", "who_what": { "question": "Who are you and what are you working on?", "answer": "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
", "keywords": [ "security", "developer", "solidity", "consensy" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "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).
When I am writing Smart Contracts, I use truffle for building and testing, intellij with Solidity plugin as IDE, Ganache, Mythril for formal verification, etc.
", "keywords": [ "ide", "mythril", "ethereum", "ganache", "formal_verification", "smart_contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "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)
", "keywords": [ "mythril", "invariant", "unit_testing", "manticore", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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
", "keywords": [ "vulnerability", "analysis", "mythril", "concept", "manticore", "audit", "knowledge", "unit_test", "formal_verification", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "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.
And 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)
", "keywords": [ "ide", "deployment", "network", "private_key", "good_ide", "identity", "integration", "smart_contract", "contract" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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...
", "keywords": [ "ide", "client", "solidity", "documentation", "dependency", "intellij", "contract" ] } }, "78": { "name": "Dandelion", "who_what": { "question": "Who are you and what are you working on?", "answer": "SourcCred - bounties and reputation for open source work.
Earn ethereum cred - reputation in the eth ecosystem for different projects
Fair distro of tokens based on who developed the project
Analyse history and collect social feedback to refine the process
Currently 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
I 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.
IPFS & 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.
Tokens flow according to software dep graph
Need 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.
Connect GH ids to eth addresses eventually
", "keywords": [ "filecoin", "ipfs", "bounty", "identity", "ethereum", "github", "fair", "open_source", "token", "history", "sourccred", "infrastructure" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
", "keywords": [ "blockchain", "token" ] } }, "79": { "name": "David Wolever", "who_what": { "question": "Who are you and what are you working on?", "answer": "Been working with Spankchain team. Combination of state channels and smart contracts.
Also worked on smart contract for ICO auction.
", "keywords": [ "ico", "spankchain", "state_channel", "smart_contract", "auction" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Vim editor, truffle. Metamask.
Switching over to onenet, using something called Vinos. Under the radar.
Vinos going to support state channels natively. Will be a little bit less terrible than Metamask.
Trouble with metamask.
Interface not well documented.
Doesn’t have promises.
Had awful error reporting.
Don’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.
Vinos will be iframed, not chrome extension.
", "keywords": [ "vim", "error", "state_channel", "documentation", "metamask" ] }, "testing": { "question": "How do you handle testing?", "answer": "First, use Truffle for unit testing.
Series 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.
Manual 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.
Tests on the mainnet actually revealed new problems that weren’t revealed on testnet
Because there were hundreds of logs per block on the mainnet, it was too many
Had to go through and make performance better on mainnet
", "keywords": [ "testrpc", "course", "transaction", "unit_testing", "truffle", "test", "testnet", "blockchain", "auction" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Front end: nothing really
Dapp: went through intense reviews.
3-5 people on a call and would go line by line through the code
Also hired a couple external audits
Even after all that, found one bug right before launch (a few days before)
", "keywords": [ "external_audit", "dapp" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Need a tool like metamask supporting state channels (Vinos will fix this)
So hard to get insights into what’s going on in solidity.
Debuggers are really hard to use.
Debugging tests is a matter of just guessing why assertions failed.
Solidity interpreter would be awesome without having to compile each time, would make development much faster.
", "keywords": [ "solidity", "state_channel", "solidity_interpreter", "test", "metamask" ] } }, "80": { "name": "James Young", "who_what": { "question": "Who are you and what are you working on?", "answer": "Work primarily with Spankchain, doing state channel research/implementation. Also worked on Adtoken, first production release of TCR.
I 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.
Before online advertising was in gaming, needed to be 100% in uptime. Game used AWS/EC2 at the time.
Looked 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.
Knew 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.
Opportunity 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.
Coming tools for layer 2 tooling. Need to have these standards, but don’t quite exist yet. This is all informed by practical implementation.
Also work on a DAO that helps multiple projects that need state channels.
", "keywords": [ "tcr", "explain", "tooling", "production", "event", "spankchain", "spank", "state_channel", "ethereum", "concept", "research", "scale", "video", "adtoken" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "We use Truffle, and Ganache on the web3 blockchain side of things. On traditional web2, use node, Kubernetes, Docker (traditional scaling pipeline).
Etherscan to verify transactions
It’s a lot of looking at Github issues. Have to support multisig contracts.
On the front-end React/Redux.
Rely 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.
", "keywords": [ "multisig", "transaction", "wallet", "redux", "state_channel", "docker", "scale", "etherscan", "ganache", "blockchain", "open", "metamask", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "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.
This 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.
", "keywords": [ "payment", "lock", "spankchain", "test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
", "keywords": [ "security", "bug_bounty", "audit" ] }, "bounties": { "question": "Other bounties?", "answer": "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.
It’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.
This 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.
The 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.
I 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.
", "keywords": [ "eip", "dao", "gas", "multisig", "wallet", "gas_cost", "private_key", "dapp", "identity", "onboard", "ethereum", "knowledge", "token", "platform" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
This 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.
", "keywords": [ "blockchain", "cryptoeconomic", "course", "economic" ] } }, "81": { "name": "Doug Hoyte", "who_what": { "question": "Who are you and what are you working on?", "answer": "Doug Hoyte, working on sportcrypt.com, a sports betting exchange. I've also consulted on a few other ethereum projects.
", "keywords": [ "ethereum", "betting" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "web3.js, ethereumjs-util, solc, testrpc, parity --dev, metamask
Overall it's pretty easy to get started, which is nice. For dislikes see next question.
", "keywords": [ "ethereumjs", "metamask", "solc" ] }, "testing": { "question": "How do you handle testing?", "answer": "Custom test harness, could never figure out how to get truffle to do what I needed
", "keywords": [ "truffle", "test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
", "keywords": [ "dependency", "test", "invariant" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Hmmm, a good light client implementation so everyone doesn't centralise around infura/etherscan, although that ship has probably already sailed
", "keywords": [ "infura", "client", "etherscan" ] } }, "82": { "name": "Ricardo Guillerme Schmidt", "who_what": { "question": "Who are you and what are you working on?", "answer": "Development of smart contracts for Status.
Can also do some web3 integration with javascript, but I have not really dug deeply into that.
I want to work on DAO’s that have delegation proxies so that you can trust an expert to vote for you.
Oraclize but too expensive.
TrueBit but not available.
Zokrates or some other solution also a possibility.
", "keywords": [ "status", "javascript", "integration", "oraclize", "smart_contract", "truebit" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Microsoft VS code, Git, Remix for manual tests, Truffle, Parity.chain for testing, Mist & Parity on Ropsten for development
I gave up on Ganache - too much variability between that and live environments.
If not already mentioned, are there any libraries you rely on regularly?
Not really, mostly backend.
", "keywords": [ "vs_code", "remix", "parity", "backend", "ganache", "mist" ] }, "testing": { "question": "How do you handle testing?", "answer": "Automated testing?
First develop the smart contract.
Manual test with Remix is the first step.
Ethercamp IDE was really good, but now it’s too old.
The new tool for Eclipse might be good but it’s only on Windows.
When it looks like it’s working, write some truffle javascript unit tests.
Usually spotting bugs happens in manual tests and truffle unit tests are just for making sure it’s good.
Remix debugger is very useful, but it’s missing some features.
", "keywords": [ "ide", "remix", "test", "unit_test", "smart_contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "No major process. “This function should do one thing. Only that. If it can be used to do anything else, that’s a problem.”
I 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.
", "keywords": [ "parity", "developer", "library" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Would be very good if VScode had the same thing that remix had - i.e. an actually Integrated IDE.
Would 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.
Solidity can’t return arrays or variable length values. Knows there is some solution with assembly but it’s too ugly.
", "keywords": [ "ide", "solidity", "remix" ] } }, "83": { "name": "Richard Ramos", "who_what": { "question": "Who are you and what are you working on?", "answer": "Smart contract developer at Status, also working a lot on Embark.
Background: I came out of TransUnion and the financial industry.
I 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.
", "keywords": [ "embark", "status", "developer", "identity", "smart_contract", "ens" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Embark, obviously!
Not just a framework for web applications - it lets you create properly decentralised applications.
You can build an app and then forget about the process of uploading to distributed file stores and setting up a lot of the infrastructure.
Embark 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.
VS Code locally and Remix to test contracts.
Working 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.
Sometimes I also use Truffle because I like the debugger they have.
A lot of tools from the JS ecosystem: node-js, React, webpack.
", "keywords": [ "embark", "evm", "library", "js", "hack", "vs_code", "remix", "webpack", "test", "infrastructure", "react" ] }, "testing": { "question": "How do you handle testing?", "answer": "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.
After executing that functionality I can then populate the code for each individual test, and this saves a lot of time.
Not really using verification tools right now.
Handle code coverage with solcoverage.
", "keywords": [ "embark", "solcoverage", "code_coverage", "execute", "test", "unit_test", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
", "keywords": [] } }, "84": { "name": "Bob Summerwill", "who_what": { "question": "Who are you and what are you working on?", "answer": "Been involved with the Ethereum community since 2015. Worked for Foundation, and then for Consensys, then at Sweetbridge. Bootstrapping current efforts.
", "keywords": [ "sweetbridge", "consensy" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "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.
Mist 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.
Infura is absolutely essential, that’s just fabulous.
Looking 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.
", "keywords": [ "embark", "mycrypto", "bridge", "javascript", "infura", "ipfs", "dapp", "brave", "parity", "browser", "community", "platform", "mist", "metamask" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
Consensys Diligence was super swamped for requests right at the start. Pay someone to stop working on their project.
", "keywords": [ "consensy" ] }, "bounties": { "question": "Other bounties?", "answer": "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.
On 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.
Back 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.
", "keywords": [ "ide", "tooling", "atom", "developer", "remix", "truffle", "smart_contract" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
Profiling, gas counting. Doesn’t exist. Anything with performance or gas counting, metrics and analysis stuff.
On 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.
Standard 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.
", "keywords": [ "sublime", "gas", "analysis", "remix", "cost", "truffle", "smart_contract" ] } }, "85": { "name": "Yaniv Tal and Brandon Ramirez", "who_what": { "question": "Who are you and what are you working on?", "answer": "Yaniv and Brandon from The Graph, query protocol for getting data off blockchains and storage networks
Focused on research and protocol design
The 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
The Graph is a Layer 2 protocol that sits on top of Ethereum that builds those indexes that makes all that data available via GraphQL.
GraphQL 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.
GraphQL 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.
", "keywords": [ "query", "ui", "protocol", "issue", "json_rpc", "network", "rest", "graphql", "design", "ethereum", "research", "community", "blockchain", "smart_contract", "infrastructure", "api" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Been using Truffle for Solidity. Remix on occasion. Etherscan on occasion. Looking at already polished contracts.
Use Parity and Geth, use Parity a lot as a Rust shop.
All 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.
Haven’t been doing so much dapp development recently. Are looking into ZeppelinOS contracts, started using Aragon for contract codes.
Struggled 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.
APM (Aragon Package Manager) is not just for Aragon contracts, is statically linked to contracts on the blockchain.
", "keywords": [ "ide", "atom", "aragon", "ipfs", "remix", "upgradeability", "etherscan", "blockchain", "apm", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "Write a lot of tests, try to make them as comprehensive as we can.
Think we use Truffle for writing the tests, all in JavaScript. Home rolled their own utilities. Don’t have anything for test coverage.
For 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.
", "keywords": [ "blockchain", "javascript", "test", "tooling" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
So far still statically including everything, would like to do more including things dynamically. But not comfortable with existing solutions.
But stuff we include statically we have to audit ourselves.
Haven’t deployed anything on Mainnet for The Graph, but are talking to firms that specialize in auditing. Want to do a full rigorous auditing.
Do a little bit of social proof, use things widely used by the community.
For dependencies, still just in development so have been pretty loose with it. Have been using OpenZeppelin, widely used 3rd party libraries.
", "keywords": [ "gas", "library", "security", "deploy", "community", "dependency", "openzeppelin", "audit", "blockchain", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "We need to ask, what are the barriers to dapps going to mainstream? Scalability, and how to make transactions fast and cheaper.
Useability 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.
LastPass 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.
For Open Source Block Explorer, the big problem is around collaboration. Problem is how to solve the problem around the nodes and to incentivize this.
", "keywords": [ "payment", "tooling", "status", "transaction", "wallet", "dapp", "state_channel", "block_explorer", "design", "metamask" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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 :)
I 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.
", "keywords": [ "type", "embark", "gas", "atom", "gas_cost", "remix", "deploy", "testnet", "contract" ] } }, "86": { "name": "Sina Habibian", "who_what": { "question": "Who are you and what are you working on?", "answer": "I started in January or February of this year, and used a tutorial on Medium for creating a voting system.
Interesting because the tutorial was already out of date by that point.
Working on TrueBit. A few smart contracts:
TrueBit core incentive layer: tasks workers who do computation off-chain
Web-assembly interpreter in solidity
Building a bridge between dogecoin and Ethereum
Haven’t really started on any front-end stuff for these things.
Interactive Coin Offering protocol that TrueBit did
", "keywords": [ "bridge", "protocol", "tutorial", "solidity", "ethereum", "smart_contract", "truebit" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Vim with solidity syntax highlighter, truffle and travis for tests
Running into problems with truffle on the current project
Zeppelin’s libraries for safe math and tokens. Using some JS state machine libraries for the client.
", "keywords": [ "vim", "library", "safe", "js", "client", "travis", "token", "truffle" ] }, "testing": { "question": "How do you handle testing?", "answer": "Truffle and Javascript unit tests
First person to build the contract didn’t use truffle, so built his own complete testing system.
Built own testsuite because truffle wasn’t configurable enough for my needs: it was running into issues as the complexity of the smart contracts grow
Deploy 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
Better to do real testing on the mainnet under a public Beta, using real ETH
", "keywords": [ "issue", "deploy", "incentive", "truffle", "test", "testnet", "unit_test", "smart_contract", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "A bunch of upfront discussions and security analysis.
Then writing tests.
Security audit, bug bounties
Then, we will run a beta on the mainnet
", "keywords": [ "security", "analysis", "test" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Testing is so important in this space, but testing is so painful and so slow.
No good debugger!!
Slow testing and debugging slow down your whole cycle.
", "keywords": [ "test" ] } }, "87": { "name": "Truffle Team", "who_what": { "question": "Who are you and what are you working on?", "answer": "", "keywords": [] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Chris:
The closer you are the foundation of the stack, the less pain you feel.
We probably cause the pain.
There’s a disparity between demand for infrastructure, and supply of engineers working on it.
I love web3 & Solidity – good open-source projects, fantastic engineers.
What I do day-to-day: development of Truffle.
Nick:
Disparity between engineers using the tools & engineers using them.
The demand for mature projects has stepped up
These tools, Truffle included, are struggling to handle mature projects, mature teams, mature practices. It’s great when people are building proofs of concept though.
The requirements are coming in pretty fast
What I do day-to-day: Truffle debugger; development of Truffle
", "keywords": [ "engineer", "concept", "open_source", "truffle", "infrastructure", "stack" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Set of tools: linters & coverage tools
Critical, have mostly been worked on volunteer basis.
Needs ongoing support; needs to adapt to changes in the stack (Solidity, Web3, …)
Should be platform agnostic, should not assume that people are using Truffle, should work with dapphub.
Leonid Logvinov wrote a 0x code coverage tool.
bounty: making a next-gen coverage tool, that can be consumed by any platform or into your tooling.
Code coverage is absolutely critical from a security point of view.
The existing system is fragile, and only has two devs working on it part-time (?)
People to talk to: Christopher Gewecke, Alex Rea (works on Solidity coverage), Leonid Logvinov (0x coverage tool)
Chris wrote the code coverage tool before joining Consensys, it’s a volunteer project.
There are also more sophisticated audit tools: Mythril by Consensys (Bernard Mueler), Oyente maintained by MelonPort is another one.
Tracing / gas-profiling?
We would like to add this kind of stuff to ganache.
Remco Bloemen working on gas-profiling.
Bounty: support for hardware wallets in Metamask
Web3 has their provider engine.
Better key management support on the web3 level.
Metamask also wants to have Ledger support.
", "keywords": [ "dapphub", "oyente", "trace", "consensy", "tooling", "wallet", "mythril", "gas_profil", "bounty", "code_coverage", "security", "coverage_tool", "audit", "ganache", "truffle", "metamask", "platform", "linter", "stack" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "88": { "name": "Preethi Kasireddy", "who_what": { "question": "Who are you and what are you working on?", "answer": "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!
Before that, I was doing independent development and was an engineer at Coinbase for a while.
", "keywords": [ "coinbase", "independent", "engineer", "cryptoeconomic", "trustory" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "With Ethereum, for Trustory, we will write smart contracts in Solidity but maybe also make extensive use of Go.
Tendermint Consensus engine to build our sidechain with.
Other Cryptolibs TBD.
", "keywords": [ "tendermint", "consensus", "solidity", "trustory", "ethereum", "smart_contract", "sidechain" ] }, "testing": { "question": "How do you handle testing?", "answer": "For JS, Mocha/Chai. In the past, used py-ethereum. For now, TBD.
", "keywords": [ "ethereum", "js" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "In the past, OpenZeppelin. Don’t think we’ll use them again because they are a bit pricey.
", "keywords": [ "openzeppelin" ] }, "bounties": { "question": "Other bounties?", "answer": "Testing and debugging!
Key management stuff.
", "keywords": [ "test" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
Testing. Surprised that there is no native tester for Solidity yet. Good examples to test using pyethereum or some other library.
Key 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.
", "keywords": [ "tester", "library", "solidity", "security", "test", "truffle", "contract" ] } }, "89": { "name": "Alexey Akhunov", "who_what": { "question": "Who are you and what are you working on?", "answer": "Been in Ethereum since the beginning. Was following the PoC. Mined few blocks on his home computer.
Initially ran geth, then parity, then geth again.
Geth said it would be more like a library.
6 months ago, moved to doing Ethereum dev full time.
Did security audits – gets tedious – smart contract are usually short. But comes with more stuff – server-side, etc
Now: playing with the go-ethereum code, trying to optimize it.
People talk about sharding, Casper, etc will fix everything; but that won’t solve everything without optimizing everything.
", "keywords": [ "ethereum", "smart_contract", "geth", "library" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Geth.
Can pass in --cpu-profile
Uses basic stuff that comes with Go: PProf.
Go has in-built tool to open this file.
Can generate dominator tree -> whole graph of traces vs times. Shows which nodes are dominating.
My workflow:
Change code.
Run geth with --cpu-prof
Generate graph from .prof file.
Run on cloud overnight.
", "keywords": [ "open", "geth", "trace", "pprof" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "Unification of testnets[a].
Rinkeby & Kovan are still incompatible.
I wanted to write this myself, write Kovan implementation in Geth?
I hate that everything in the smart-contract ecosystem is written in Javascript – e.g. Truffle. People then use truffle bindings in production.
Native go tooling. Native go contracts.
I 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.
Specific: 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.
", "keywords": [ "type", "contract", "tooling", "rinkeby", "production", "js", "javascript", "dependency", "testnet", "safety", "truffle", "smart_contract", "geth", "kovan", "unification" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "90": { "name": "Simon de la Rouviere", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
Started building on Ethereum when it was announced in 2014, and then more actively late 2014, working in the stack.
Currently most time on: Ujo music - decentralized licensing platform for musicians.
30% of time on Curation Markets - monetize new networks of value and coordinate toward shared goals.
", "keywords": [ "network", "ethereum", "platform", "decentralized", "stack" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "I am the smart contract lead at Ujo, so spend most of my time writing Solidity and tests.
Writing tests in Truffle and to deploy contracts.
Generates 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.
Sometimes 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.
Just truffle’s contract libraries to interact with frontend
Use Oraclize for on-chain price oracle for Ujo stores.
Strings library built by Nick Johnson that helps us parse strings in the registry more easily.
Wrote our own ERC-721 implementation as well.
After 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.
Also just helps with my own understanding to write this stuff myself.
Curation market specific tools?
Trent 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.
We use a lot of different curves for curved bonding markets, and there are some curves that are more easily visualized and assessed.
xkcd graphs makes some interesting and easy to understand stuff.
", "keywords": [ "ide", "consensy", "library", "atom", "protocol", "deployment", "network", "solidity", "error", "community", "test", "token", "oraclize", "truffle", "smart_contract", "metamask", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "Mythril is very useful and we use it.
Writing 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.
It really depends on the use case: i.e. checking for over- or underflow means you sometimes need to be really careful.
Best resources to learn about tests?
The EVM is notoriously bad at providing good error reports.
Revert with reason will be really helpful for this. But there might still be edge cases where it is not certain what transpired.
You used to require a lot of context in order to sense what
A 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).
Solidity 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:
Explicitly setting the constructor (to avoid some of the Parity hacks)
Addition of transfer function to automatically check for failure of sends (which was previously manual).
After DAO hack, I started collecting information and Smart Contract best practices repo, which is now maintained by the Consensys Diligence team.
Infura 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.
However, 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.
", "keywords": [ "dao", "trace", "unit_test", "tx", "contract", "evm", "mythril", "test", "smart_contract", "consensy", "client", "solidity", "error", "truffle", "safe", "hack", "infura", "resource", "parity", "knowledge", "context" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "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
A lot of curation market stuff: usage, governance and management of the community.
There 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.
The 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.
It’s kind of like network effects for investment or VC.
", "keywords": [ "governance", "status", "issue", "bot", "bounty", "nft", "token", "community" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
Wouldn’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.
In the future, if you’re going to have 1000’s of GB of media, this will need to be looked at much more closely.
Protocols labs multi-hashing scheme is very useful in addressing the content.
", "keywords": [ "content", "swarm", "protocol", "network", "infura", "ipfs", "access", "platform" ] } }, "91": { "name": "Alvaro", "who_what": { "question": "Who are you and what are you working on?", "answer": "VirtuePoker – offchain game, smart contracts to represent state of a poker game – offchain consensus of consensus, and submit to onchain.
Building poker with Ether, that can be played without an intermediary.
When you leave the table, you cash out with the stake which you have left
", "keywords": [ "smart_contract", "virtuepoker", "consensus" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "92": { "name": "Javier Franco", "who_what": { "question": "Who are you and what are you working on?", "answer": "VirtuePoker –– making the migration to the new problem.
We have a Proof-of-Concept on Python; implementing in Electron.
Talking to Plasma, to use for scaling and also gas costs. This is a big problem.
The 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.
Offchain stuff:
P2P 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.
Building 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.
", "keywords": [ "virtuepoker", "gas_cost", "network", "cost", "scale", "backend", "regulatory", "plasma", "api" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "Testing our Dutch Auction ICO contract:
We were targeting 100% code coverage.
The contract allowed ICO to stop in two ways:
By hitting the market cap
By calling stop (?)
The time between the auction being finished, and the tokens being claimed, you want 7 days.
This is equivalent to 30k blocks.
How to test? You hardcode lower numbers, test (which is slow), then switch in the real numbers.
What a solution for this would look like:
These tools could have a way to mine the number of blocks you want, instead of block-by-block.
Stress-testing the economics & game theory of ICO contract:
To be able to bid, you need to be whitelisted. Then, the amount you bid is also limited.
Solidity:
It’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.
E.g. Parity bug. All contracts where using the same contract.
E.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.
We are moving towards factory or library-driven contracts.
We will have a proxy contract.
", "keywords": [ "ico", "game_theory", "library", "solidity", "parity", "test", "token", "code_coverage", "auction", "contract", "economic" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "How to simplify the way to calculate the gasPrice.
Having an estimateGasCost when you send a transaction?
A 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
Wallets need to implement this, it would help a lot of people.
", "keywords": [ "wallet", "gas_cost", "gas", "tx" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "93": { "name": "Rick Dudley", "who_what": { "question": "Who are you and what are you working on?", "answer": "I worked on EthPM briefly.
I gave up in frustration
I was working at Monax at the same time with RJ and Jan.
This is a good bounty that we’re going after.
Bigger problems within EthPM:
Fundamentally, in Ethereum, we have contract immutability.
If 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.
Working on at the moment?
VulcanizeDB with Maker as their client.
Steps:
Take IPFS (the content-address allows you to verify the content is correct) and retrieve the data
SQL query – you do a search given parameters and you get back a result set.
Because you trust the database is free of faults.
Vulcanize: our result-sets contain content-addressable data.
ETL system for blockchains.
Pull blockchain data into a Postgres database – load all blocks, transactions, tx receipts.
You as an engineer write a transformation – which also generates a GraphQL endpoint.
Your dapp can then pull that data on an ongoing basis live –– pubsub, polling, … The data is also content-addressable.
e.g. you put the events for a contract into a table, you have a block range, a contract, in this table
Then, you take that table, do a pg_dump, and put it into IPFS.
You can then verify that using your own client.
Github / vulcanize / vulcanize.db
Will be released soon.
Will eventually write a DSL for those transform.
Standalone vulcanize db reads from one node, but can gossip the transformed to other nodes.
Interactions with IPFS, Tendermint, Lightning, …
Federated exchange – decentralized exchange
Once you have that system; then the Tendermint validators can have a system marketing
Tendermint validators can be bonded on Ethereum AND they promise to route the Bitcoin HTLCs
", "keywords": [ "vulcanizedb", "query", "network", "database", "ethpm", "tx", "contract", "engineer", "bounty", "dapp", "ethereum", "decentralized_exchange", "tendermint", "client", "ipfs", "github", "sql", "testnet", "maker", "monax", "content", "transaction", "event", "graphql", "deploy", "etl", "blockchain" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "I like the DappHub stuff; but it’s not fully integrated.
There isn’t a full testing suite; no way to go from the Solidity integration tests, to full-stack integration tests.
Casey Detrio worked on testing & fuzzing within Ethereum Foundation codebases.
But they don’t run simulation networks on updates, so there could be consensus breaks.
For instance, the airline industry does this. Airlines use BFT within fly-by-wire systems.
Check out: videos from SQLite author explaining how they did testing.
Our testing:
We use both Zeppelin and Dapphub.
Phantom-js test of something that uses IPFS and Ethereum.
Monax had a lot of great tools, that didn’t get the attention they deserved in the community:
Counterintuitively, the federated context has higher security requirements. Your clients ask tougher questions than ICO token buyers.
", "keywords": [ "consensus", "ico", "js", "network", "token", "video", "community", "explain", "ethereum", "test", "zeppelin", "dapphub", "fuzzing", "ipfs", "solidity", "client", "stack", "monax", "security", "context", "integration_test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "94": { "name": "Evan Van Ness", "who_what": { "question": "Who are you and what are you working on?", "answer": "Have only ever played around very early, but never built anything seriously
Personality isn’t suited to writing bug free software, which is what you have to write in this space, and not a serious enough developer
The idea of writing code with actual value attached to, direct value that you can never take back in the case of an error.
I’m glad others are developing, but I would lose too much sleep.
I run the Week In Ethereum newsletter, and has become a full time job at Consensys.
Close to 40hrs a week to curate
Do a podcast as well.
Moderator of r/ethereum
", "keywords": [ "moderator", "consensy", "developer", "error", "ethereum" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "95": { "name": "William Entriken", "who_what": { "question": "Who are you and what are you working on?", "answer": "Started using Ethereum in December.
Created ERC721/161 to support my project. It was contentious, I won the fork wars.
Underestimated how crazy this ERC721 process was.
721 is the first standard that’s actually an Interface.
Interfaces are broken in Solidity.
Started filling bugs in Solidity. –– interfaces should be able to inherit from interfaces.
External vs public in interfaces. I fixed it.
Fixing things in Solidity –– basically rewriting the whole inheritance model in Solidity.
In 721, I had a caveat section, “errors in Solidity etc” ––
People said: “the standard shouldn’t say a function is payable” –– but I said that the interface needs to enforce this.
Got the attention of Christian, Alex, Hudson.
721 had a dependency on 165. So I started to fix 165.
Mainly occupied with full time job, speaking re: 721 and its use cases at conferences, evangelism, million dollar homepage, navy, google, hardware (semiconductors)
Big open-source guy, worked on KDE project, worked in semiconductors.
", "keywords": [ "solidity", "error", "ethereum", "dependency", "open_source" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "96": { "name": "Christopher Goes", "who_what": { "question": "Who are you and what are you working on?", "answer": "Wyvern is an application agnostic protocol for exchange of transactions, not tokens
Parameterisable orders - kitties with blue eyes, discovery mechanism
NFT, bonds, collateralized debt obligations, pools of cats, where people care more about the parameters of the asset
Buying and selling of smart contracts. Use case- rental of smart contracts in exchange for fees
Like the 0x for transactions, ethereum assets
Proxy account system where users create DEX orders that execute transactions under specified conditions.
Abstracting over Ethereum bytecode - anything you can send over eth transaction you can buy/sell
Mostly written in January 2018
", "keywords": [ "wyvern", "discovery", "protocol", "transaction", "dex", "nft", "ethereum", "execute", "token", "smart_contract" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Solidity, Typescript, Truffle for deployment, JS front end
Bytecode checking handled by libraries
Bytecode of your order (constructed in UI) is checked vs orderbook
How are you building the front-end to construct bytecode?
https://exchange.projectwyvern.com/
Wyvern schemas library maps bytecode to visual representations
", "keywords": [ "ui", "wyvern", "library", "deployment", "js", "solidity", "typescript", "truffle" ] }, "testing": { "question": "How do you handle testing?", "answer": "Oyente
SolCoverage is super useful
Javascript tests
Current experience writing tests in solidity is terrible. Could be better with a better interpreter.
Current static analysis tools focused too heavily on reentry bugs, post-DAO
Security audit on Wyvern revealed that a non-zero contract balance tool
More edge cases needed between Solidity and EVM gotchas
", "keywords": [ "dao", "oyente", "wyvern", "evm", "analysis", "solcoverage", "solidity", "security", "audit", "contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Local, easy Solidity interpreter
Currently, tests are done on EVM through a blockchain
Most things you’re testing don’t rely on blockchain features (timestamps, block # etc.)
Easy interpreter that runs locally on computer not through ganache
Also, Better gas measurement- line by line gas cost analysis
His workaround was using solidity assembly code (well documented)
User account experience would be better if people used contracts instead of standard accounts
Wyvern already uses user-owned smart contracts as their user account
Instead 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.
Custom rules for fraud detection/reversal could be set up (i.e. double confirmation/ time period required for transactions > $xxxxx)
", "keywords": [ "wyvern", "evm", "gas", "transaction", "analysis", "solidity", "limit", "solidity_interpreter", "test", "cost", "ganache", "token", "blockchain", "smart_contract", "contract" ] } }, "97": { "name": "Matt Condon", "who_what": { "question": "Who are you and what are you working on?", "answer": "Built a raffle contract, but didn’t ship it because I didn’t want to deal with real money in early 2017
First thing I shipped was steak.network
Now building XLNT and gnarly
Solidity contracts.
Off-chain clients.
Frontend interfaces for blockchain-backed stuff.
", "keywords": [ "raffle", "gnarly", "network", "client", "solidity", "blockchain", "contract", "xlnt" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle, Infura, MetaMask, Etherscan, Remix, Solidity flattener.
If not already mentioned, are there any libraries you rely on regularly?
Web3, BigNum, moment, Numeral, Chai, Mocha
", "keywords": [ "mocha", "chai", "numeral", "etherscan", "truffle", "bignum" ] }, "testing": { "question": "How do you handle testing?", "answer": "Try not use truffle test.
Never written a solidity test, but written a lot of JS tests.
Also do some manual integration tests using Remix to deploy to Ganache or something. Using remix for this testing.
", "keywords": [ "js", "solidity", "test", "ganache", "integration_test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Nothing, no real process besides following best practices.
Gets auditing. Should be running Mythril but hasn’t set it up yet. They have a great blogpost on finding unchecked self-destruct.
", "keywords": [ "mythril", "audit" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Truffle has a lot of rough edges (documented elsewhere)
Gas profiling
Interactive debugger that works
", "keywords": [ "gas" ] } }, "98": { "name": "Ramon Recuero", "who_what": { "question": "Who are you and what are you working on?", "answer": "Last summer, developed Redis on Ethereum. Simple to read & write data.
", "keywords": [ "redis", "ethereum" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "", "keywords": [] }, "testing": { "question": "How do you handle testing?", "answer": "Redis had the smart contract. Made an npm library; had Truffle tests + npm tests.
", "keywords": [ "redis", "smart_contract", "test", "library" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "Found a list of the top 10 security vulnerabilities; reentrancy, math overflow, ...
You don’t know what you don’t know.
How to find info:
Google / reading about the DAO hack / Reddit.
", "keywords": [ "overflow", "dao", "reentrancy", "vulnerability", "hack", "security" ] }, "bounties": { "question": "Other bounties?", "answer": "Having difficulty in hiring people – most engineers don’t understand blockchain.
Don’t have much to show for it right now.
SoV
Infrastructure needs to get exist first.
Lack of use-case, to be honest.
Explaining the data model for blockchains:
E.g. similar to: Dan Abramov: Redux devtools on the right.
Making an interactive demo of data flowing through.
", "keywords": [ "explain", "engineer", "redux", "blockchain", "infrastructure" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "99": { "name": "Facu Spagnuolo", "who_what": { "question": "Who are you and what are you working on?", "answer": "I studied Computer Engineering and am a full stack dev. I started my career by programming web stuff and distributed systems.
A year ago I had heard a lot about BTC and “blockchain”, so I got involved.
My life goal is to build the technologies that will make people’s lives easier and more free.
Cryptocurrencies 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.
I 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.
This 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.
Auditing well-known projects also really helped me grow my knowledge of how the whole ecosystems works and what the best practices are.
I am now building Zeppelin OS - upgradable smart contracts, with a scheduler, and on chain standard libraries.
It’s a huge challenge to build this on Ethereum currently, so I became a core member and we are releasing our first version today!!
", "keywords": [ "evm", "library", "tutorial", "security", "ethereum", "vm", "community", "knowledge", "scheduler", "blockchain", "smart_contract", "platform", "zeppelin", "stack" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Truffle - I don’t really like it, but have to use it.
We can improve a lot of things here and build some more things on top of it.
Testing your contracts easily across any network and setting your own defaults through the console is not as easy as it should be.
Truffle 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.
We should start thinking about providing an interface that can be consumed, extended and used by other cmd line tools, and things like zeppelin_OS.
The 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).
I 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.
When 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.
We 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.
Currently 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.
Say goodbye to all those deploy-time issues ;)
We 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.
Ethereumjs-abi, ethereumjs-utils etc.
Web3 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.
MetaMask is also really useful - makes life easier in so many ways.
We use both geth and parity as we have our own nodes to test things.
Remix is really cool and it works really well. I encourage people to use it and look forward to new releases from them.
Sharing sets/suites of contracts easily can be improved.
", "keywords": [ "zeppelin", "ethereumjs", "gas", "library", "event", "issue", "network", "transaction", "dapp", "remix", "deploy", "test", "log", "truffle", "smart_contract", "metamask", "contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "We use Travis CI.
Coverall for coverage tests, also for solidity coverage using solcoverage as a plugin. Super useful to us.
Write plain mocha tests (integration and unit) and we aim for 100% coverage always.
When working on DApps we usually have standard paths to test how the UI works.
This is another developer tool that is missing: a tool to test UIs when signing transactions.
", "keywords": [ "ui", "ci", "transaction", "developer", "dapp", "integration", "test" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "For governance:
We 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.
It 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.
Having 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)
We 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.
", "keywords": [ "governance", "evm", "decision", "investor", "transaction", "compiler", "gas_cost", "library", "bounty", "upgradeability", "token", "scheduler", "community" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "100": { "name": "Manuel Araoz", "who_what": { "question": "Who are you and what are you working on?", "answer": "Open Zeppelin: open source smart contract framework
Currently working on building web app
On chain libraries with upgradability
Contract interaction
Marketplace
Scheduler for asynchronous execution.
", "keywords": [ "contract", "library", "open_source", "scheduler", "smart_contract", "open", "zeppelin" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Use the truffle toolkit the entire way. Truffle for testing.
Publish on npm for users to use open zeppelin.
One of the first to try ethpm.
It was super buggy with IPFS errors and it couldn’t find the resources and stuff
", "keywords": [ "resource", "ethpm", "error", "ipfs" ] }, "testing": { "question": "How do you handle testing?", "answer": "Truffle automated testing with javascript unit tests
Migrated to async/await style of tests
Mocha, Chai
Onchain bug bounties for finding implementation bugs.
", "keywords": [ "test", "bounty", "chai" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "We design first then develop.
Sometimes they see other teams mix these two phases.
This is bad, because you can break your assumptions in nuanced ways..
", "keywords": [ "design", "assumption" ] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "Upgradability
We’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].
Upgradability requires governance mechanisms though, and these are more difficult to figure out, as it is not just about code.
We are not working on debugging, but would love to see someone solve it
We use the truffle debugger but it’s not covering all their needs
Remix is good, but we would rather not use the web UI.
Better tools for deploying and managing contracts on the blockchain
We’re building this (John & Marcus)
Tools to replay past transactions
E.g. for historical testing of upgrades.. replaying transactions from previous versions and making sure they don’t break.
Stress-testing cryptoeconomic system: we only really do human analysis now.
Better tools – like simulations of the mechanism design to prevent game theoretic problems – would be cool. This can be a bounty[b].
", "keywords": [ "ui", "governance", "library", "transaction", "analysis", "cryptoeconomic", "bounty", "deploy", "test", "blockchain", "contract" ] } }, "101": { "name": "Brendan Chou", "who_what": { "question": "Who are you and what are you working on?", "answer": "On chain derivatives for erc-20 tokens
Open sourcing their code in next week or two
Only smart contracts protocol so far, no UX/Dapps
", "keywords": [ "protocol", "dapp", "token", "smart_contract", "open" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Remix for smart contracts
Writing Javascript tests
Truffle for compiling and test, NPM to manage packages,
SolCoverage
", "keywords": [ "solcoverage", "javascript", "remix", "test", "smart_contract" ] }, "testing": { "question": "How do you handle testing?", "answer": "Mocha, js unit tests on Truffle
", "keywords": [ "mocha" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "", "keywords": [] } }, "102": { "name": "Lane Rettig", "who_what": { "question": "Who are you and what are you working on?", "answer": "Core developer for EWASM, but independent and works on a grant.
Doing a lot of governance-related stuff lately, EIP0, Fellowship of Ethereum Magicians
Runs a blockchain community and coworking space in NY called Crypto NYC (www.cryptonyc.org)
New project called Odin Protocol, an open data marketplace
", "keywords": [ "eip", "governance", "coworking", "odin", "independent", "protocol", "ewasm", "developer", "crypto", "ethereum", "community", "blockchain", "open" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "Use vim, tmux and work way down in the protocols - no web3 etc.
Lots and lots of helpful vim plugins: various language syntax plugins, version control, etc.
Writing web assembly itself (tests), Javascript and some C++: evm2wasm transpiler that can maintain backwards compatibility.
", "keywords": [ "vim", "wasm", "evm", "protocol", "javascript", "test" ] }, "testing": { "question": "How do you handle testing?", "answer": "", "keywords": [] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "", "keywords": [] }, "bounties": { "question": "Other bounties?", "answer": "", "keywords": [] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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.
", "keywords": [ "wasm", "evm", "ci", "js", "test", "infrastructure" ] } }, "103": { "name": "Kames", "who_what": { "question": "Who are you and what are you working on?", "answer": "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.
Getting developers to understand how to implement this in the front-end environment, get people that are not used to Ethereum to understand this
Ask the right questions to get people thinking about this
", "keywords": [ "developer", "identity", "ethereum", "community", "uport", "decentralized" ] }, "tooling": { "question": "What are the tools/libraries/frameworks you use?", "answer": "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.
Use 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.
", "keywords": [ "ipfs", "react", "ethereum", "cost", "react_native", "test", "redux", "spec" ] }, "testing": { "question": "How do you handle testing?", "answer": "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.
Could use a better audit tool. Can test smart contracts at a code level, formal verification but haven’t researched this.
", "keywords": [ "consensy", "research", "test", "formal_verification", "smart_contract" ] }, "smart_contract": { "question": "How do you handle smart contract verif & security?", "answer": "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.
Had them audited by Consensys internally, possibly by the diligence group.
Getting 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.
Deprecating 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.
", "keywords": [ "consensy", "protocol", "identity", "upgradeability", "audit", "formal_verification", "uport", "smart_contract", "contract" ] }, "bounties": { "question": "Other bounties?", "answer": "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.
Better UI/UX, thinking about this next layer. Get product people, designers, etc. involved. A Material design for dApps.
", "keywords": [ "design", "platform", "dapp" ] }, "missing_tools": { "question": "What tools don’t exist at the moment?", "answer": "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
Need tools that enable quick validation in the real world. Need better prototyping
Design systems, design patterns, how to handle long transaction times. New thinking in this regard.
", "keywords": [ "design", "dapp" ] } } } const Questions = [ { id: 'smart_contract', text: 'How do you handle smart contract verification and security?' }, { id: 'bounties', text: 'Other bounties?' }, { id: 'who_what', text: 'Who are you and what are you working on?' }, { id: 'tooling', text: 'What are the tools/libraries/frameworks you use?' }, { id: 'frustrations', text: 'What are your biggest frustrations?' }, { id: 'testing', text: 'How do you handle testing?' }, { id: 'missing_tools', text: 'What tools don’t exist at the moment?' }, { id: 'domain', text: 'Other domain specific questions?' }, { id: 'ethereum', text: 'What was the hardest part about learning to develop with Ethereum?' }, { id: 'short_term', text: 'What are you most excited about in the short term?' }, { id: 'ease', text: 'Was anything easier than expected?' }, { id: 'other_people', text: 'Who are the other people you think we should talk to?' }, { id: 'resources', text: 'What are the best educational resources?' }, { id: 'other_questions', text: 'Are there any other questions we should be asking?' } ] module.exports = { InterviewData, Questions }