From adde5e0a0eb9db784a46a4de02f3f8f8b64b4b25 Mon Sep 17 00:00:00 2001 From: Wisani Shilumani Date: Fri, 20 Jul 2018 10:27:44 +0200 Subject: [PATCH] New JSON structure transform --- components/browseArchives/index.js | 16 +- .../interviews/singleInterview/index.js | 2 +- data/archives/interviews.js | 8528 +++++++++++++---- 3 files changed, 6754 insertions(+), 1792 deletions(-) diff --git a/components/browseArchives/index.js b/components/browseArchives/index.js index 01379c6..e6c1d39 100644 --- a/components/browseArchives/index.js +++ b/components/browseArchives/index.js @@ -7,7 +7,7 @@ import TopicsList from '../topicsList'; import ProjectsList from '../projectsList'; import SearchBar from '../searchBar'; import SearchResults from '../searchResults'; -import { InterviewsData, Questions } from '../../data/archives/interviews'; +import { InterviewData, Questions } from '../../data/archives/interviews'; import './style.scss'; class BrowseArchives extends React.Component { @@ -22,7 +22,7 @@ class BrowseArchives extends React.Component { isInterviewsListModalOpen: false, activeSingleInterviewId: 1, isSearchActive: false, - interviewData: this.transformInterviews(InterviewsData), + interviewData: this.transformInterviews(InterviewData), matchedCount: 0, }; @@ -118,21 +118,21 @@ class BrowseArchives extends React.Component { for (let i = 0; i < length; i++) { const interview = interviews[i]; - const qKeys = Object.keys(interview); + const qKeys = Object.keys(interview); // name, who_what->question const interviewFormatted = []; - qKeys.forEach((key, index) => { - if (key !== 'Name' && interview[key] !== null) { + qKeys.forEach((key) => { + if (key !== 'name' && interview[key] !== null && interview[key].answer !== null && interview[key].answer !== '') { interviewFormatted.push({ - question: index, - answer: interview[key], + question: key, + answer: interview[key].answer, }); } }); betterInterviews.push({ id: i + 1, - name: interview.Name, + name: interview.name, matchedIndex: -1, interview: interviewFormatted, }); diff --git a/components/interviews/singleInterview/index.js b/components/interviews/singleInterview/index.js index 4519546..c8e4ccb 100644 --- a/components/interviews/singleInterview/index.js +++ b/components/interviews/singleInterview/index.js @@ -36,7 +36,7 @@ SingleInterview.propTypes = { }).isRequired, toggleSingleInterview: PropTypes.func.isRequired, questions: PropTypes.arrayOf(PropTypes.shape({ - id: PropTypes.number.isRequired, + id: PropTypes.string.isRequired, text: PropTypes.string.isRequired, })).isRequired, }; diff --git a/data/archives/interviews.js b/data/archives/interviews.js index 42f47f9..e61c075 100644 --- a/data/archives/interviews.js +++ b/data/archives/interviews.js @@ -1,1792 +1,6754 @@ -const InterviewsData = { - '0': { - 'Name': 'Fabio Berger & Remco Bloemen', - 'How do you handle smart contract verification and security?': '

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.

', - 'Other bounties?': '

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.

', - 'Who are you and what are you working on?': '

0x - Decentralized exchange protocol. It is a set of smart contracts that handle standard transactions in an order format.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Getting a simple experimental environment up is hard

Remix is there; but it’s not enough.

Tracing and profiling is not existent.

Remix does it, but can’t do it locally.

“Code coverage” tool exists but inserts console.logs in

Adding up gas costs per line of code.

Need to do profiling, because gas costs depend on inputs.

Solidity language itself:

Crashed the Solidity compiler twice today.

E.g. AbiEncoderV2 is pretty new and hard to understand/use.

The code that it produces is inefficient.

There is a stark stack limit in solidity

All the variables are locally scoped.

Un-intuitive as it is a curly braced language.

The lifecycle hook value_of is within a function.

Can only access top 16 slack slots. Including input and output.

We need to implement a graph coloring register allocator – to find out what the lifetime of the variables is.

“This stack slot was used in the first half –– the second half you can use”

Or implement register splitting.

Function inlining is frustrating sometimes:

E.g. SafeMath –– turns every operator into function call – which is a huge gas sink.

How Solidity optimizes could be improved:

It focuses on the code size (which makes sense since it’s minimizing the state tree); but sometimes you need to optimize size of tx gas (e.g. 0x needs optimized fillOrder call)

ABI doesn’t implement introspection

EIP 165

E.g. “does this contract implement ERC20, or ERC223?”

Solidity should have this in-built.

Should be built into the API spec and compiler.

Inheritance:

Interface or abstract contract – e.g. Solidity automatically creates getters for state functions –– collides with

Contract which implements an interface – public or external for abstract functions – they collide

ERCs – there is not a formal way to describe the interface for contracts.

Have a standard repo –– this will lead to a canonical ABI definition –– can have semantic rules around this. Could run some specific unit tests against

', - 'How do you handle testing?': '

Testrpc has gotten better ––

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.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '1': { - 'Name': 'Leo Logvinov', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

There is a limit on local variable numbers (have a limit of 16, which influences how you write the code).

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

', - 'Who are you and what are you working on?': '

Started in blockchain 2 years ago in Berlin, working on Ethereum devtools, building solidity plugin for IntelliJ, built by him and an Australian.

Working on truffle, did some PRs, improving speed, usability, error handling.

Started working on 0x, primary role: devtools team.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Event watching - unreliable, no support for backfills etc.

Build tool for statically typed contract (ABI gen that generates contracts), build out the statically typed libraries

Negative experience with web3js team - unresponsive.

Frustrated with truffle because it is hard to contribute with so many packages these days.

Hard to debug and understand it all - so needed a smaller truffle for the specific use cases.

Need to standardise their artifact format (currently in talks about it).

Solidity coverage tool: built at hackathon (at least the profiler which is not super useful), standardise on artifacts format so that it works across tools.

Which line of solidity is covered by tests?

EIP712 - standardised signing for structured data, also helped finalise 721 at ETHDenver.

Solidity plugin for IntelliJ IDE

One did not exist at the time. Did not have too much stuff in it really: simple formatting, definitions, highlighting. Not “a super interesting” project, but has 36 000 users (some duplicates).

VMs

Been wanting to speed up tests recently. Bottleneck is code execution in Ganache VM (90%). We want to get down to 1-10s test runs.

GAS PRICES ARE NOT THE SAME!!!! Arghhhhh!

We need JIT compilation in more performant language (currently just executed in JS).

Project called EthJIT VM, transpiles to LLL, then optimizes contract so that it is precompiled and then runs much faster.

Would be great to see the integrated in ganache (snapshots and time travel make this a nice tool than geth to use currently).

Even better to have pluggable VMs, have spoken to the Foundation about this too.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

Prettier type plugin for solidity. I don’t have time to write it but Prettier has a good API.

', - 'Other domain specific questions?': '

What has your experience been like working on EIPS?

Working on EIP 712 - signing structured and typed data

Quite hard with monetary prospects and no established legislation process - need better ways of governing and enforcing the process.

Really helped to have everyone in one room at ETHDenver and align on angles of attack.

Room at ETHDenver from commenting on a thread in GH. Started unstructured and moved into structured discussion by defining the interface, which helped identify all the different parties’ motivations. This revealed some inertia on some teams’ behalf, which was interesting to see.

Lot of discussions about metadata (of tokens, which is also important for other parts of tokens)

GH PRs are one single wall of text and the comments need to be better moderated, especially for trolls or tangential discussions/ideas (especially tangential ideas need to be collapsed).

Creators need to moderate/create a TL;DR section to help people better and more easily grasp what they are working on.

Solidity code coverage - how does that work?

Before each line calling eval, and modifying Eth and ganache code to read the events, much below the current block gas limit and working through everything that comes through.

Take debug transaction with list of opcodes. Also have the source maps, which map back from opcodes to lines of solidity code, and can use that the work backwards from opcodes to understand exactly which line used how much gas.

How do you get the trace after each tx?

We wrote our own provider, whenever call to eth_sendTransaction gone through provider it sends it and then gets the trace.

Calls don’t have traces though, so need to do a snapshot and then send the call as a tx, which gives you the trace back and then you can look at what happened in the call.

Did look at other tools, but felt the performance and reliability of those tools just kinda sucked.

Can you tell us more about Event Watching?

Lacking good open source project[a]

People don’t have stateful nodes, you need to handle events client side

Ethereum-js blockstream enables us to use stateless nodes after installing all filters. Still not a part of web3.

Working on something called order-watcher: track when the order becomes invalid. Which happens when the user manipulates things. You can validate reactively by watching for events, but you want to actually watch balance changes and events are just an imperfect proxy for this.

People can mint and burn tokens and change balance without emitting events.

Want to track changes in balances, not events. balanceOf() is view function that returns the balance, so we want to track the result of calling that.

Might be inefficient to look at that directly, or we can register callbacks and recompute only when the state used by that function changes.

But how do we know when state changes?

Cannot rely on solidity, but can run function, get trace, see which storage slots the function is reading, and then you for sure know that this function will only change its value when one of those storage slots changes.

Use Patricia tries somehow to watch these storage slots and state changes - allow you to watch efficiently changes on view and pure functions.

Check out EIP 781: https://github.com/ethereum/EIPs/issues/781

Can you tell us more about ABI gen for statically typed contracts?

Contracts need to be checked at compile times to ensure parameters etc (strong instead of number or something like that) and being statically typed is much easier to check this.

Inspired by geth tooling, and there are also some JS ones (salt-size etc) but were all very opinionated and made all sorts of assumptions about how you wanted to use your contracts.

With 0x tool: Consensys is using it, Sybil (journalism tools, also with typescript contracts).

Using ethers.js for backend of contracts due to issues with web3 versions (classic).

Best ideas to have in a debugger?

Not writing solidity actively at the moment and I haven’t used one yet because it is such a high level tool (haha).

I feel that this is quite a long way away right now.

Need bytecode, source code, source maps, traces, interruptable VM etc.

Can you tell us more about signing data in Ethereum?

Arbitrary string that people were supposed to sign, but then people figured that you could use it to send ETH, hence the weird prefix that got implemented - not an EIP, it is just a bugfix.

If there is a way to display user data and get them to understand the transaction fully, then they would surely not sign. Prefix doesn’t solve anything, it just postpones the problem.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '2': { - 'Name': 'Axel Ericsson', - 'How do you handle smart contract verification and security?': '

Human thinking and auditing.

Will find some external team to do a professional audit.

', - 'Other bounties?': '

Breaking out a javascript library for web pages that are accepting payments, which allows you to accept any kind of wallet mechanisms: Ledger, Metamask, Priv key, encrypted keystore, etc.

Same thing needs to exist for desktop software. Need a simple desktop wallet that accepts any kind of access to payments.

', - 'Who are you and what are you working on?': '

I have built 1Protocol

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.

', - 'What are the tools/libraries/frameworks you use?': '

Just web3JS and the python raiden client

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

Truffle suite. Before that, built our own unit testing system.

', - 'What tools don’t exist at the moment?': '

There is no tooling or anything related to state channels that is trusted yet.

Need the MEW of state channels.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Solidity is changing so quickly that, as an example,

changes to visibility modifiers (public / private etc.) has gone through a view iterations.

It would be great if there was a resource that combined solidity read the docs with the github releases[a][b]

Needing to resolve problems like how to setup web3, talk to contracts, remote vs constant transactions. Lots of re-implementing solutions.

', - 'What are you most excited about in the short term?': '

Raiden is the golden egg in the space. The experience of actually using Ethereum will improve a ton.

“Counterfactual” team building some general purpose state channels.

Less bullish on actual applications on Ethereum right now.

', - 'Was anything easier than expected?': '

Writing smart contracts is surprisingly neat. Not actually as hard as it seems. You can have a mental model of all the moving pieces in your head, which is actually harder with other kinds of software.

', - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '3': { - 'Name': 'Mike Goldin', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Pretty cool to have more languages for the EVM. Solidity is only reliable one. Yoichi’s Bamboo is moving along.

', - 'Who are you and what are you working on?': '

Software developer at Consensys

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.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

Truffle’s debugger is a bit disappointing. Works well for simple pattern, doesn’t support different types of contracts i.e. proxy pattern.

Need an Ethereum Package manager. Wishes packages were update. Should move from Ropsten to mainnet. Publishes and consumes to EthPM. Adoption is still low- EthPM.

Made technical assumptions early on, problem could only be discovered when going into production. User data you get from running on a testnet. People’s behavior changes as you add real money.

Offline simulations of incentive games with $10,000, offline IRL version.

', - 'How do you handle testing?': '

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

', - 'What tools don’t exist at the moment?': '

Fuzz Testing and formal verification desired.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Hardest part is learning to develop in a blockchain environment, not solidity. Learning the javascript versus learning the browser. You can learn the language formally but learning how to apply the language in the browser. Blockchain environment is very different from anything else.

', - 'What are you most excited about in the short term?': '

Excited for Casper

Applications implemented in Plasma, generalized state channels.

', - 'Was anything easier than expected?': '

What’s really easy is programming money.

On blockchain, every individual has universal payments identifier.

', - 'Who are the other people you think we should talk to?': '

Infura team, client development

Spankchain - pretty aggressive on focus to

', - 'What are the best educational resources?': '

Solidity Docs

Uses yellow paper gass lookup table

Not sure

', - 'Are there any other questions we should be asking?': null - }, - '4': { - 'Name': 'Oleksii', - 'How do you handle smart contract verification and security?': '

We have written our own tools which tell us, for instance, that “this variable is never used.”

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Our original vision was to do everything – testing, deployment, etc - through Truffle.

But, in reality, we’ve only used for testing.

First version of truffle was using the testrpc snapshots for reverting – good for unit testing.

In second, third versions this was removed.

Most companies use truffle for testing, on testrpc.

We made our own helper to make snapshots and do reverts on testrpc before/after tests.

Now, you can deploy the contracts from inside the tests; you’ll have a freshly deployed contract.

Truffle’s designed to be used by a single project –– a fixed set of contracts that doesn’t change much.

But most of our projects have different platforms, so we end up deploying different versions of our contracts over and over again.

When Ethereum started being regularly congested

Built functions to overcome this – tool for: re-submitting transactions with higher gas prices when they don’t get accepted.

People don’t track nonces correctly:

Tool for: figuring which nonces were skipped, and creating transactions for them.

We check for compiler errors + static warnings in Remix.

I haven’t used automated tools like Securify.

I just read the contract for as long as possible, so that I understand the contract as if I wrote it myself.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

What are other great tools you have used?

Ethercamp – a smart blockchain explorer:

Heuristics while parsing and indexing the chain.

Had a convenient interface to explore the storage of the contract; even without an ABI, the heuristics allowed you to see that e.g. “this key is this address”. And then showed this stuff in a human-readable way.

Then, they kind of stopped their resources.

More details on you data collection & devops tools?

For it to be useful, it requires time for refactoring.

It’s usable right now, but code could be improved.

Making complex deployments possible.

It won’t be too complicated to build.

Tool for: pulling balances of some tokens of some addresses

Tool for: making airdrops cheaper to do. E.g. 20k addresses with batch deposits happening through a smart contract.

LLL language?

If you’re using Solidity, you can’t have the maximum optimization in your contract.

Convenient way to write contracts in Assembly?

He wrote bytecode by hand, for the contract they deployed a million times.

Having a better low-level language that compiles to bytecode.

The call trace in Ethereum?

It doesn’t currently provide you with any help.

Using 4byte.io, you have the ABI of all the functions in the trace.

You can build a human-readable layer above it, and see what’s going on.

Can have a real stack trace for function calls between contracts, with what values.

Action items?

Oleksii to outline needed features / requirements for smart deployment tool.

Us: intro him to others interested in in collaborating on above & scoping out requirements.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '5': { - 'Name': 'Brett Sun', - 'How do you handle smart contract verification and security?': '

Human audits only right now.

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

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

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

My biggest general frustration comes with the relative youth of the whole industry, which underlies a lot of our collective frustration, including both security and development.

It feels like we sometimes have our hands and feet tied when we are trying to make something. When you make a typical web app, there is a lot of freedom in tooling and the tooling is robust.

You can make changes easily, watch these changes propagate, feel productive, and get feedback immediately.

This is not the case on Ethereum - things that should take a day actually take a week or a month.

Estimation of time is really difficult, but especially in Ethereum given how many unknown unknown there are.

It’s really easy to get started, but it gets harder and harder to maintain.

Now that we have a lot of stuff built out, we now have to maintain it, and that decreases the rate at which we can ship new features as there is a lot of old architecture you need to deal with.

Feels like we’re playing a lot more defense than offence. Was first introduced to this by Jon Choi: you should be proactively pursuing offense and limiting defense (i.e. innovation over optimization).

All of these tools that are “not quite robust” tend to waterfall a lot, which means we are consistently on the defense, even against the tools we’re using.

No teams are really at the level of engineering that we need to be at. It’s all shooting from the hip right now, which we fall into too because we want to ship things quickly.

There are no really great patterns or best practices or frameworks to follow just yet, or at least a shortage of them in the ecosystem.

Every year in traditional ecosystems, a new testing framework will come out, which is really great and I would love to see a similar situation beginning to happen in the Ethereum world.

', - 'How do you handle testing?': '

In addition to the above we also use solidity-coverage, which can be super painful too. Not sure if the most recent version has fixed some of the issues, as we haven’t yet upgraded (we pin our contracts to an older version of solc for security reasons after they have been audited with a specific compiler version).

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.

', - 'What tools don’t exist at the moment?': '

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...

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Google + Github is my go to.

Not enough has been written on effective workflows for building decentralized products with new and largely untested tools. We need more developers writing about their experiences. Even if it is just a simple Tip & Tricks list or Awesome List.

For instance, I consider the Consensys Smart Contract Best Practices repo to be really helpful, especially for people coming in. Something like this would be great for general workflows:

How to debug transactions, for instance.

', - 'Are there any other questions we should be asking?': null - }, - '6': { - 'Name': 'Jorge Izquierdo', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Infura that is more decentralized. A full-node infrastructure[a].

An open-source explorer.

', - 'Who are you and what are you working on?': '

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

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Tell us more about getting deep into the EVM?

Natspec lets you evaluate functions within call – this is problematic security wise.

It’s not turing complete at this moment

No one describes what transactions are going to do; Radspec is the answer to this! Everyone use it, please.

Standard around commenting exactly what a transaction does.

Documenting what the source code does

Solidity puts a hash of the code, at the end of bytecode.

This process of automating the comments could be automated; pulls comments from Solidity source code, add them as comments for devs

Integrating dApps with blockchain?

Local caching in the browser; what are the block numbers; do a Reduce to see how an event impacts the state.

Problem with the caching layer: the info not only comes from the Event, but data you get back from contract depends on the block number

Performance is an issue:

Augur: ethereumjs-blockstream.

Library-driven development & upgradability?

If Solidity changes how variables to storage blocks, if it changes this, there’ll be problems. They want to build a tool that does a sanity check that checks still works[b]

Tool to do a sanity check over the storage layout

If new contract uses different version of Solidity, could get that directly through proper use of interfaces.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '7': { - 'Name': 'Jack Peterson and Sparkle', - 'How do you handle smart contract verification and security?': '

Pay others to think about it - no process yet. We write a bunch of units tests, and we are going to run things through Oyente (Formal Verification).

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': null, - 'What are the tools/libraries/frameworks you use?': '

Back-end: Visual Studio Code with docker images that run pythereum for unit tests.

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)

', - 'What are your biggest frustrations?': '

Lack of a debugger - by far the biggest issue.

Need to print things from failing transactions and can’t do this

Right now, we just attempt the transaction until it doesn’t fail. We are often unsure why things fail, just keep going until it doesn’t. What’s missing is break points and executing code from that. That will shorten feedback cycles.

Development environment is really bad right now…

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

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.

', - 'Other domain specific questions?': '

Let’s talk specifically about UI issues / scaling?

Stabilisation of contracts: we need clearly defined API’s against contracts.

When you change behaviours on a contract it has a multiplicative effect on the UI. One small change can have effect where you change 10 views. This lengthens dev cycles and having an API defined is important.

In general, it is hard to write business logic layer. Augur is writing a middleware node to overcome this.

Impractical to fetch large amounts of data from blockchain - it’s too slow. It takes a minute and half to get data (how do you manage that experience in the UI?). Running a remote geth node - fetching data from logs + contracts is not fast either. This can be improved.

Have an Augur node or SQL database -- pre-fetches and pre-processes Augur gnodes to make them available… But this also constitutes an annoying extra thing between ETH and client which can be slow / unusable.

Lookup mechanisms are primitive!

Size limit on contracts is really annoying -- can’t deploy to Ropsten because of it. It took significant engineering to put something on testnet (had to 51% attack it to increase block size).

Getting TestNet eth is hard --- not a way to get a good amount of rinkeby (can only get a little bit from faucet -- don’t want people spamming it with transactions)

Really intense test suites running against Ropsten (Raiden…)

Would be great if we could easily spin up private chain to deal with that. Build a service to spin up private test nest that would have a certain amount of nodes.

Currently, this takes days of work -- what about standard service to do this?? People run these in different setting -- EC2 that is configured would be very useful.. Could store copies of Rinkeby and boot them up when people ask for them… (Infura will evolve into this)

What would be the hardest part of teaching your Mom how to use a dapp?

How ETH account is different than an account on a regular website.

Few ways to login to Augur -- can create an account on the website, but you have to keep track of it (like creating an account on the website).

Airbit will create accounts for Augur that will behave like regular website.

Had 2 bounties -- posted on Bounties Network -- and it worked

Linter rules -- portable debugger

Unit tests die and you attach a debugger to it -- nobody supports break points.

', - 'What was the hardest part about learning to develop with Ethereum?': '

What steps do I need to follow to write these apps? Isn’t anywhere here that helps you that much.

Development cycle for Augur has been roughly three years - and mostly not development stuff. We had first working version of Augur on testnet after 4 months (been iterating since then).

It worked, but it didn’t scale and we found security problems. One can’t release software with bugs in it. So this weird balance needs to be kept as we cannot actually “move fast and break things”

Start with simple system and iterate on it.

Only way to do it is to do it on testnet first! There, you inevitably encounter edge cases or developers notice something.

', - 'What are you most excited about in the short term?': '

Raiden is coming shortly and will be very cool.

Looking forward to Proof of Steak.

UPort going live will be cool on Rinkeby. Is now integrated with Augur.

Nothing blocking Augur yet.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '8': { - 'Name': 'Joey Krug', - 'How do you handle smart contract verification and security?': '

Yeah, encourage everyone to use auditors. Lots of multisig tools out there that don’t have CI builtin. Oyente, Mythril, but one problem is that no one else really uses them. Lots of bugs they found.

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Co-Chief Investment Officer at Pantera Capital and Co-Founder @ Augur.

', - 'What are the tools/libraries/frameworks you use?': '

At Augur, stack is different as it’s a bit older.

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.

', - 'What are your biggest frustrations?': '

At the end of the day, it all comes down to the tech side. Biggest frustrations are that it’s hard to write scalable software on something on Ethereum. State of scalability is very nascent. Product he’s advising for payments, they look at state channels. But when you try to use MVP’s, it doesn’t work. But it’s really a comment on scalability not on the individual company. L4 working on generalizable state channels, excited about that.

From a business standpoint, you want to build on Ethereum. People come to them and say they want to build EOS. Reason Ethereum doesn’t scale is that they’re trying to scale and not make a huge compromise. But there isn’t a lot of marketing. We want to articulate why Ethereum is a good platform to build, not just look at TPS.

Would be cool if Ethereum Foundation put some posts on the blog for what’s in the works for everything.

', - 'How do you handle testing?': '

Run against pyethereum. Test suite is written in Python. As an investor, most companies are in JS environment with Truffle. Like Python a bit more. Truffle complaints are it has a lot of quirks. Default instructions for setting up tests in Truffle you get a weird nested stack of tests.

UX blockflow IDEO for Truffle, doesn’t need to be rewritten but needs to be improved.

', - 'What tools don’t exist at the moment?': '

My answers changed over a time, 1 year ago it was static analysis. These tools exist now, but they need to be improved. The tools themselves don’t have test suites, for example and they need more firepower in general.

From an investor standpoint these dev tools need to be improved.

', - 'Other domain specific questions?': '

Would be useful if the Ethereum project could add more firepower to underlying network. Propagating a block and you have a certain amount of time to do it otherwise you could fork;. More low hanging fruit at the network level.

A really simple idea is when blocks are propagated, just propagate the tx ordering. Then have clients gossip for missing tx’s. A concrete example is for Bitcoin Bip152. Could this work Ethereum? Make something like this for Ethereum. Implement in Geth in Parity

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

In the short term, he’s most excited about Maker DAO in the wild. A good stable coin.

Scalability for mid-to-long term focus. 4 years ago it was just discussing what the block size is, but that’s an improvement for just one time. Interested in sharding implementations.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Back then documentation was very sparse, blogs posts or Reddit posts written by Vitalik or other people. Try stuff and see what works, back then everything was on Skype. Now it’s quite a bit easier, Solidity docs are much better.

What about for people getting into the space now? Google + original docs + Stack Overflow. If you’re stuck go to one of the Gitter channel and ask the question.

', - 'Are there any other questions we should be asking?': null - }, - '9': { - 'Name': 'Mark Beylin', - 'How do you handle smart contract verification and security?': '

Consensys diligence is an auditing team available for their teams.

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

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Creator of the Bounties Network. Bounties on any task in any Ethereum token. Frontend that relies on Infura and IPFS.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Not being able to upgrade my contracts easily.

Better ability to return data, specifically variable length data. Arrays of strings. Mappings of strings to data, etc.

Ability to just dump the whole state would be great.

Gas limit:

Gas costs are high. Gas limit was a problem very briefly when trying to deploy a contract. But if your contract is running into the gas limit, it’s probably too big.

Off-chain computation:

No. Smart contract doesn’t care about off chain. Stores stuff on IPFS and just stores the hash on-chain.

State Channels:

Only read about them and researched how they could be used.

', - 'How do you handle testing?': '

Mocha tests using Truffle and testrpc.

Also use Rinkeby for when deploying staging versions.

', - 'What tools don’t exist at the moment?': '

Better querying possibilities on the state of contracts. Better indexing to do this. Even something that will just shoot results into a SQL table.

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

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Didn’t understand the stack. People don’t understand what’s in between dapp and the blockchain.

Really solid boilerplates would be very helpful for new people to see how easy it could be.

', - 'What are you most excited about in the short term?': '

Sharding. That’s all I want.

uPort is getting ready for mainnet, feeling excited about that.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Joseph Vander (learning the be a solidity developer right now)

Kevin Owocki from gitcoin

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Curious to know about developer incentives. Assuming you can make the same amount of money, would you prefer to build your own project or work on other people’s more established projects?

E.g. bounties for Augur vs building your own little dapp

' - }, - '10': { - 'Name': 'Aidan Hyman', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Working with parity and geth and parity-bridge. Optimising the EVM for bespoke needs - could be for clients, for enterprises. Lower level focus.

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!!

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

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.

', - 'What tools don’t exist at the moment?': '

Mythril for the EVM stack. Rewrite a complete stack visualizer for the whole EVM. Add opcodes to the stack and see how it looks programatically and logically would be awesome.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Two of our most exciting projects:

Shift - decentralized KYC/AML platform.

Bunz - a hyper-localized bartering solution. Started as FB group, grew to 60 000 users all bartering locally in Toronto. The people weren’t just bartering anymore, but using gift cards, subway tokens, beer bottles, anything that could be converted into transactable good. Crypto can be the main medium. Currently have 200 000 users on the app and website and over 1 000 000 items available.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Honestly just readthedocs, gitter channels and searching through GH issues.

Moved from slack and gitter, to riot and gitter, and also ethereum stackoverflow.

If there is an issue, go to those repos as it is so unlikely that you are the first person to experience an issue using Ethereum tools.

Hardest to learn about the stack and opcodes

Find the right local communities and get involved with them. Pair programming and being equally confused together is really helpful.

', - 'Are there any other questions we should be asking?': null - }, - '11': { - 'Name': 'Greg, Stu, David', - 'How do you handle smart contract verification and security?': '

Mythril, as mentioned above.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

David: EVM layer stuff: interactions between opcodes, JS dev and web3 also comes into this at the other side

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

', - 'What are the tools/libraries/frameworks you use?': '

JetBrains suite as an IDE. Remix comes in there for extra convenience but has it faults and is not totally integrated.

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.

', - 'What are your biggest frustrations?': '

Up to date documentation!!

System dependence stuff would also be great to include (Mac OS/Windows/ Linux)

Thing s are fairly minimal, often have to hack together things yourself because the specific functionality you need is not implemented

When doing tests, get very unhelpful errors. Make them more specific! EVM errors in general are garbage.

Their error handling, geth specifically, basically used the same error in most cases to propagate it out. Go through subsections of EVM and write proper errors[a].

Are you going to be using revert with reason in that case?

Call contract that deploys another contract. If gas is too low, it will just revert with no clear error. Needed to raise the gas, and it took 3 days of trial and error to figure it out (not clear if they will be or not, answer was more general about past problems they have had)/

', - 'How do you handle testing?': '

Mostly unit tests in mocha and chai.

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?

', - 'What tools don’t exist at the moment?': '

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?

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Greg: Looked at web3 documentation (as it was more web based stuff at first).

Truffle pet shop worked well for a lot of people

David: Ethereum wiki was starting point, but you HAVE to talk to people about it.

Reinforcement comes through discussion and USE.

Stu: some limited solidity tutorials, go on to gitter and ask questions with code snippets nd other organic community involvement.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': '

Community! Going to EDCON was an eye-opening, validating experience. Impostor syndrome is real and the remote work can be very isolating, but you can also own that and it is inspirational to see.

Perfectly OK to make stuff up as you go.

Availability of people, and the amount of people who can and will answer your dumb questions.

Also, it’d be awesome to actually put computer science background to use.

', - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Where do we actually find out more about all these tools? ← highlight top-mentioned tools in report.

' - }, - '12': { - 'Name': 'Jon Maurelian', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

I work at Consensys Diligence doing audits; similar to Zeppelin.

Also, I do technical communications / writing blog posts about best practices around security / Consensys docs / token repos.

', - 'What are the tools/libraries/frameworks you use?': '

We use Truffle a lot (never had to use Dapple or Embark)

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?

', - 'What are your biggest frustrations?': '

Auditing:

A lot of my time is spent understanding what the developer was trying to do. There’s lots of back-and-forth and I want to maximize the probability that this is the only audit the company needs to do (end up doing a lot of free work this way & comms);

I would like to see better standards in what the idea of “ready to launch” is / what docs should exist / what the depth of testing should be.

https://media.consensys.net/preparing-for-a-smart-contract-code-audit-83691200cb9c

I want to see:

More efforts on gas optimization.

Using Assembly to do things.

Use different languages.

One thing that kills me:

When people copy-and-paste from Zeppelin or other libraries.

As an auditor: do I run a git diff?

Large inheritances.

Ugly repos. Not tidy. Clean directory structure is key.

These are real contracts.

These are testing contracts.

Wrote blog post so far.

What are most prevalent errors:

People should use EPM to import / or Dapphub.

Add linting -> Solehint (?) / Solium.

What happens in a security audit:

Run the tests. Usually because of different truffle or testrpc version.

Have npm scripts to run local version of truffle.

The easier it is to read tests, the better.

Self-referential tests.

Code coverage. Want all code to be run during testing; important code to be run multiple times.

Test the full specification.

Static analysis: we use a tool called Nifroll (?)

Look at Solc warnings & analyze bytecode.

Reading the code is the most time-consuming part. Best opportunity to make us all more efficient: automated tools to help auditor pay attention to right parts.

This is the most annoying part of the process.

Devs need to have written down their intentions for the code.

Specification is evidence of thoughtfulness.

Use Oyente; but it doesn’t find anything new generally.

We also think through game-theoretic attacks:

E.g. front-running (transaction-ordering stuff).

What’s ideal process for testing:

1) run local testing

2) run that test suite on some testnet.

Put system on mainnet with 2 week bug bounty.

E.g. ENS bugs weren’t caught on testnet. There was a typo that didn’t get caught.

Want: more scenarios were there’s economic incentives to break the system – vs. just out of good will of devs spending time.

Documentation around best practices external to writing smart contracts

E.g. how to safely deploy your system.

There’s easy tricks how to make this easier..

There’s lots of operational & security related info to share..

Bounty this into one doc as resource list.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Piper Merriam

Nick Johnson

Christian Lundkvist (@ Consensys)

Joseph Chow (@ Consensys)

Mike Golden (@ Consensys)

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '13': { - 'Name': 'Nick Dodson', - 'How do you handle smart contract verification and security?': '

Mythril will be useful when in full bloom - need more oversight on contracts in general

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Working on experimental infrastructure. ARES, GovernX.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

Data verifiability problem - nobody is going to another source of data

Run your own local system and test whatever is run by Infura vs. your system -- should be able to test this against your own local Dapp

Not a lot of utility to compare -- would be great to have library and testing script

Protection mechanism to keep an eye on infura -- ecosystem driven thinking to reduce amount of trust to test what they are giving us

Exchanges should be running internal nodes to make sure getting the right data - need something to compare their node to Infura

Build a Dual Provider. Make a little library, connect your own provider and Infura, and then compare that both are behaving the same. Verify yourself

ETH.JS Stuff - small items

Websocket support

Moving ABI module to Richard’s module

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Tell us more about TCRs and DAOs?

There are many groups that need it for protocol or token

Rendered basic systems and services that we really need

Notifications - if you’re in governing body, you need to be notified via normal devices to conduct governance

Working on notification systems for TCR’s, multi-sigs, Aragon DAO’s

Scraping chain data and issuing emails - databasing and emailing. Should be easy to do.

Verifiable chat system - most governance is about the conversation.

Low level real time, high performance, contractually restricted chat. This is centralized, but data storage is decentralized and data content is verifiable.

Can be encrypted using RSA

Will spin out live chat for ecosystem - enhance dapps with real time live chat

Data / Statistical Analysis - Alethio (deep rich blockchain analysis system)

Lots of data coming in for governing structures - no reason to load from Infura

Reporting and data analysis on governance structures

What is participation like?

How well is a TCR performing?

Off-Chain verifiable polling - votes and data are verifiable

Coordination is only attack vector.

Final tally is rendered sum of onchain and offchain sum

How can off-chain channels be made into a near-front end experience?

How are API’s made in a very simple manner

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '14': { - 'Name': 'Ilan Benbrith', - 'How do you handle smart contract verification and security?': '

Consensys Diligence provides some of the best resources and best practices online

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

I’m the Technical PM at Consensys Academy working on an 11-week developer program. I’m responsible for maintaining the course and making sure people reach their development goals.

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

', - 'What are the tools/libraries/frameworks you use?': '

Truffle, Ganache, Remix, Metamask etc.

Front end

React Native

LLL, Front end libraries

We give wide exposure

', - 'What are your biggest frustrations?': '

Gas and fees is a common frustration, given that they are an extra consideration that must be taken into account. Test Ether required.

Speed, once launched on mainnet latency is frustrating.

', - 'How do you handle testing?': '

Truffle testing

Best practices resources

', - 'What tools don’t exist at the moment?': '

Drizzle is a really cool idea for front-end development

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': '

We’re still so early on but we hope to incorporate feedback for now.

', - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Youtube videos

Conferences and Meetups - putting names to faces, seeing others’ pain points

Watching someone build out an application

', - 'Are there any other questions we should be asking?': null - }, - '15': { - 'Name': 'Goncalo Sa', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

None come to mind right now. Let’s keep the focus on EthPM here - we need to make sure as many people use it as possible! We should have done this a long time ago and we need to dogfood it as a community!

', - 'Who are you and what are you working on?': '

I work at Consensys Diligence - focus on security of the ecosystem. Everything that is related to security: it’s on our roadmap to tackle it.

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.

', - 'What are the tools/libraries/frameworks you use?': '

I used to use Remix a lot more than I do today (though I still use it heavily).

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.

', - 'What are your biggest frustrations?': '

I really, really want a good visual debugger. I don’t think I’m alone on this one either, but I also don’t think people are as passionate about this as I am.

My main motivation behind this is that I really like visual debugging and it is just so much easier, when debugging a very low level program, to have a visual aide.

It requires real experience to reason about things at a very low level and see the effect of each line of code.

Remix, right now, has a very steep learning curve and we are missing the opportunity to make sure that every developer coming in gets clear insight into the nitty gritty details, the fine print, of the EVM that actually gives them full control over what they are doing and what they want to do.

I feel that very contained environments are usually more appealing to people just entering the world of computers and programming.

When Apple started with Swift playgrounds and lots of integrations, I saw a bunch of people just flocking into iOS development. It was just so easy to understand what is happening - it’s all very visual and easy to grok.

', - 'How do you handle testing?': '

Remix, Surya and Mythril as above.

Very small number of instances where I need to do something off chain, for which I will then use Truffle.

', - 'What tools don’t exist at the moment?': '

A proper, local dummy client. I love the Truffle team and I love Ganache, which I use a lot.

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.

', - 'Other domain specific questions?': '

What are the details/patterns in smart contract audits you see often that people should not be writing?

People are lacking the granular insight that is required - along with the right mindset/philosophy/paradigmatic approach to writing smart contracts. This goes back to the need for better visual tools, in my opinion.

A lot of contracts do not acknowledge that they are operating in a resource-constrained environment. For instance, I see lots of loops - which is not a desirable thing when operating on top of Ethereum.

People also don’t have that “asynchronous mindset”, unless you have been working with a very strange stack indeed. Even people coming from JS and pure node backgrounds - it’s not quite the same thing.

They keep favouring push mechanism when there should be a pull one (or vice versa).

In reality, this is a very hard question. I do have a collection of very specific stuff I have seen people do wrong, but - in a very general manner - the biggest problem is bringing synchronous patterns into smart contracts.

Thinking of a way to have them do otherwise, this whole thing is promoted by people not getting what is actually happening beneath their code. They know it is “distributed”, but what does that mean to them? Hence the need for something like a Swift playground in order to make it easier to grasp the use of resources on the network

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Bernard Miller from our team, focussed entirely on Mythril.

', - 'What are the best educational resources?': '

I do this less frequently now, but I basically watch every interesting repo to know what they are doing next before any announcement or anything.

I also spend a lot of time reading the docs in that repo. In fact, a couple years back, I would spend most of my time reading those kind of docs.

Also, the Ethereum wiki has a lot of super involved stuff that is not easy to grasp and there should be somewhere where those things are explained far more simply.

Again, I’m a very visual guy, and that wiki really lacks graphics and images that could be really helpful in terms of giving a wider group of people insight into the innards of the systems.

Things like RLP encoding, Patricia-Merkle tries, or the ABI sender (which I went back to over and over again until eventually getting to a sort of Eureka moment re encoding reference types). I feel like the tries, in particular, are very visual things.

RLP graphic resources would really help because it is such a specific thing.

The Beige Paper is awesome, but it’s still not the end game - it’s too technical still with almost no visual guidance still requires a very big leap for people dealing with blockchain for the first time.

', - 'Are there any other questions we should be asking?': null - }, - '16': { - 'Name': 'Fabiano, Jordan, Nick', - 'How do you handle smart contract verification and security?': '

Audit code: bounty hunt program, found one major one via community. Ran our own repo specifically for this on Github.

Community auditing through bounty programs.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Cryptokitties! Goals they have are to get multiple millions of users, the sooner the better. Ethereum sharding would be very nice, but even then there are scalability problems. Looking into other chains, EOS, Neo, Cardano Looking at things from a scalability perspective.

Back-end stuff reconciling state of the world between blockchain and their stuff

', - 'What are the tools/libraries/frameworks you use?': '

Been a while since we have done smart contract development, haven’t done any since we deployed. Truffle framework, TestRPC (now Ganache). The standards at the time.

', - 'What are your biggest frustrations?': '

The lack of proper debugging support. That caused us to lose so much time. Even more than the slow compiles.

Biggest pain points:

When we were using Solidity, some safety features were added later, especially visibility modifiers on functions.

The compiler is very slow. Recompiling took ~30 seconds slow. T

ests were slow as well.

No easy way to debug.

Debugging tool for Solidity, what would it look like?

Write “debugger” and it stops there.

Breakpoints, step through code.

Quite difficult to log something through a function. It would revert if it failed, even logging was failing. If a require failed it would be tough to find error.

Planning on working on contracts soon? Or moving on?

Have plans for a MetaData extensions, push kitty images to IPFS, and have kitty image as a piece of metadata for the cat. That’s the big one.

Front-end:

web3 is the only library required. The web3 works as any wallet solution has the implementation web3.

Web3 1.0 beta, 0.26. On webapp they are on web3 1.0 beta, seems stable for the browser.

Read and write functions for the contract, nothing crazy.

The problem with web3 0.2: docs are not great at all.

', - 'How do you handle testing?': '

Standard testing and using community to audit contracts

', - 'What tools don’t exist at the moment?': '

2 main areas with significant problems:

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

', - 'Other domain specific questions?': '

Have you written any open source tools for scaling?

Looked into side chains and micropayments.

Side chains as implemented in something like Raiden don’t allow people to build off what they build. On side chains kitty hats would not be possible.

Cryptokitties run son chain. Sidechains aren’t the option, but Plasma is really interesting to us.

Are you writing your own Plasma stuff?

We’re looking for options that allow them to scale.

Plasma seems possible in theory.

We chose Ethereum in the first place because infrastructure is good, Metamask, Infura, etc.

', - 'What was the hardest part about learning to develop with Ethereum?': '

The real problems come into play when you are very dependent on 3rd party apps, in their case MetaMask. Memory problems in Metamask. Can’t really detect the state of Metamask. Stuck in a situation where they can’t provide the relevant info to their users

When a user does something, it’s kind of a hope for the best situation. May take a long time. If a user buys something on Amazon, they get a confirmation in 30 seconds. In blockchain, we can’t guarantee that info. Spent a lot of time educating users. Less with the libraries and more with the user communication and understanding of blockchain.

', - 'What are you most excited about in the short term?': '

The thing we are excited about most in the next 3-6 months is whatever ends up being the scaling solution

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Solidity documentation was quite good. Had all the jumping off points.

Random mishmash of articles and whatnot :)

', - 'Are there any other questions we should be asking?': null - }, - '17': { - 'Name': 'Andy Milenius', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

DappHub:

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Ethereum relies heavily on Javascript dev tools; “that node modules way of life”.

Javascript: its polarizing; you either love it or hate it.

The fact that there’s a JS tool for something doesn’t mean that it doesn’t need to exist otherwise.

Examples:

Piper’s python tools

(would like to see C++)

Maker’s bash tools

Some dapphub Haskell tools

EF should put money into language ecosystems; replicate what we have (more front-end library systems!)

Second layer tools - the Ethereum API is a huge pain point.

RPC - if you’re on the command line, it’s a pain in the ass.

High-level access into the Ethereum API; more granular than the REST API

In JS this is: Web3.py; in python its web3.js

Small drop in solutions for talking to a client

Why is there not a good robust solution for caching the blockchain in a normal database?

Maker has funded this.

VulcanizeDB done by Rick Dudley; Maker is funding

When you talk to Infura, the Ethereum API, is mostly via HTTP. Need sockets.

If you want to query events, it’ll probably time out.

It will be cool if EF runs archive nodes, cached data.

Feels bad about Metamask:

If you only used them to write to blockchain, then it would be so much simpler for them.

Metamask just pipes all the requests to Infura; costs around 100k a month.

The reason why everyone uses Metamask, is because there’s no other robust solution. If EF funded a solution, it’ll be helpful

Metamask is customer support for the entire Ethereum ecosystem.

Event querying

Make it so that it’s not scanning for the whole blockchain.

Light clients

Everyone’s trying to build the perfect architecture. Metamask is trying to build something that works.

Metamask’s version:

An awesome intermediate step:

Infura publishes a block onto IPFS using pubsub

All the metamask nodes gossip it to each other.

Could EF support this.

There is someone publishing all blocks from all blockchains on IPFS, into a meta-blockchain, called Braid.

Whisper & Swarm:

There’s other people still working on these outside of ETH

Swarm is similar to IPFS.

Does ETH need p2p messaging

There’s systems that work:

DAT protocol / secure scuttlebut (1,000s of people on these networks)

Ask the Secure Scuttlebut ecosystem what their issues are

Dfinity gave a grant to secure scuttlebut

It would improve the Ethereum community image if we’re working with others.

Identify other projects that are good; trim the fat from our ecosystem; and then build a relationship with them.

“Living life on hard mode” – people who don’t do ICOs.

Other ecosystems that are good: show commitment to Protocol Labs

Libp2p

IPLD

More formal partnership -- integrating properly

Devp2p is bad

Less than 1% of requests you make are Ethereum mainnet.

You contact other nodes without knowing if they’re on Kovan, Mainnet etc

Super inefficient; all these handshakes.

Main bottleneck in Geth -- every ETH node talks on Devp2p

Gotta switch to libp2p!

Are Geth team dynamics good?

Idea: a parallel IPFS pinning service; as a hedge against Filecoin not working.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

How can Ethereum create more cultural norms and lead by example?

Take a more leadership role to say nice things about other ecosystems, languages etc.

Ethereum Comm’s department.

' - }, - '18': { - 'Name': 'Esteban Ordano', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Biggest request: have ERC20 upgraded to ERC223.

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Pains:

The gas issues – the expensiveness of the whole process.

We are subsidizing the whole process of deploying the land.

We are also subsidizing the second transaction after the ERC is assigned.

This whole process will take 12 million, 150 ETH.

We also had to make the contract upgradable – with the delegate proxy pattern

We are worried that Solidity will change, and the structure of storage will change.

Our thinking: we’re doing some engineering on how to sell the next batch of land – we came up with a better system to sell that land – it’s going to be pretty neat. We’re not going to have this issue.

Decentralized exchanges:

Looking forward to 0x adding a version of their protocol for non-fungibles. Which has now happened! https://blog.0xproject.com/introducing-0x-protocol-v2-9f5bda04d38d

State channels:

Looking forward for Raiden

Was thinking of funding Lightning Network for ERC20 network

Simulating a UTXO model on ERC20 tokens

Wants for interoperability between Bitcoin and Ethereum.

Olaoluwa (from Lightning) is the best coder in the world.

Bitcoin world is more secure.

Lightning code is written like poetry.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Should speak with Fede –– should collaborate together –– they’re interested in throwing money at sidechain & Plasma chain.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '19': { - 'Name': 'Matias Bargas', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

I used to be an investor, but came to crypto and Decentraland at the same time.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

Real monitoring information is tough to come by. I come from enterprise where this stuff just exists and the ability to fetch the data you want to fetch is never really in question.

Browsing through a node that has a huge list of unindexed transactions without all the information you need in an easily accessible place is hard.

With our own tools, we are building our own framework in order to move tx information from the blockchain to the db and from the db to the app.

We need transformations between each layer (which wasn’t that hard to build). But now we need a really generic way to do this and to publish it for people building DApps and using our SDK. And with a centralised DB, this is not possible.

We are failing with dev tools in general.

Let’s think about Java a bit. You have the JVM, a mature language and a complete set of IDEs. You also have a tonne of framework for building Java applications. There are also great monitoring tools.

Logging systems are a great and practical example of this. How can I log failures from Solidity without using events in a way which they weren’t really intended to be used? We need a Splunk equivalent.

Terraform, AppDynamics, etc - these things don’t exist for blockchains and really need to be built.

We need to focus more on tech and shipping things and less on the people with money or how our token is performing.

We care about nothing but the tech we ship. We encourage others toward similar feelings ;)

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

Starting from the infrastructure stuff: we need a new language to describe all the set of things that you need to do in order to deploy one or more contracts.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

The Decentraland client!! Woot woot.

Something that helps me to generalised solve side channels.

Status.

', - 'Was anything easier than expected?': '

No, not really.

Actually, extending the open zeppelin stuff was pretty easy.

Someone tried to exploit Decentraland and because we validate with open zeppelin it was safe, and we got that for free!

It’s great to see that security is taken seriously (though I still have a tonne of concerns about managing funds on public networks).

', - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

I came from a strange backend doing tooling for languages for the last 6 years, so I don’t have the right approach to learning for most, I think.

Should be readable, reliable and consistent. E.g. I prefer typescript over js because it behaves as expected and has been validated by the communicated. Java > python because it also behaves better and more in line with your expectations. I need a language with only one way to do things.

If Solidity fulfilled this, why do we need to test it with javascript?

I never did any course, I just read contracts and code that seemed interesting.

Started with Zeppelin’s ERC20 and went from there through GitHub and started writing little tweaks and commits myself.

I had also had some experience with React, so that set me up well for DApps.

Having awesome and intelligent colleagues is such a bonus too!

', - 'Are there any other questions we should be asking?': null - }, - '20': { - 'Name': 'Nadav Hollander', - 'How do you handle smart contract verification and security?': '

Write down in plain text documents what the invariants are for the contracts. Just very clear human speak for how the contract should behave.

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

', - 'Other bounties?': '

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.

', - 'Who are you and what are you working on?': '

Building Dharma - open protocol for tokenized debt

Pretty much exclusively at the contract level, sometimes using stuff like libraries that wrap around contracts.

', - 'What are the tools/libraries/frameworks you use?': '

I like to use Typescript for testing.

0x team built a great tool for generating typescript tests from ABI’s

Using truffle to test.

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

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

', - 'What tools don’t exist at the moment?': '

Good logging and debugging

Setting up your own side chain easily to test things on because it would be way faster

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

“What is the thing that makes debugging solidity code the hardest?” (for me, it’s that you can’t log anything at all, and no working debuggers)

' - }, - '21': { - 'Name': 'Alex van de Sande', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Finding talented people is very hard. They are in such high demand. Trying to get people out of school. Online courses in Solidity.

Web developers, software engineers.

Separate recruiting approaches for the Foundation.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Securing Electron (desktop JS) was hard. (JS in website can take over your system - happens with chrome)

Integrating with other technologies: IPFS, Swarm, etc. Frustrating that they are all in their early days.

Information overlap - this is a major problem - e.g. in keeping up-to-date with Solidity developments, even though I’m on the Foundation.

A lot of people have been trying to integrate this information without success

I like two things from the Foundation:

Daily standup for Geth team.

Every quarter Vitalik and Ming post an update on what happened in the Foundation.

To be improved at the Foundation:

On the operational side:

Make the foundation more open, more modular with their finances. Each team should have more autonomy, with their finances transparent on the blockchain.

On the technical side:

Autonomy would play into this as well.

What are you excited about:

Casper.

Sharding.

Applications: Aragon, MakerDAO.

', - 'How do you handle testing?': '

People build new features, we check, and then approve it.

We’ve had issues –

Meteor.js migrating to React.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

One dev working on a backend integration – I stopped working on this to work on one issue – “password wasn’t working for user” – couldn’t reproduce the bug. Could put a bounty for someone to recreate the bug & solve it.

Different systems: Gitter, Github issues, different wallets

How we solved: created a single issue with all comments from other issues. Created google form for anyone who had an issue, to see if there’s a pattern amongst problems.

What type of expertise is needed for this: we don’t have enough security oriented people on our team. We passed the bug reports to the Foundation security person, who tests them.[a]

Single case: serious bug report came in and was fixed. But couldn’t test the fix, because they would have run exploit on their machines. They don’t have pen testers.

Wanted – less of a wall between their team and the outside.

Need: Recurring open source developers --- that are working for bounties --

They haven’t tried bounties yet.

Is the problem: dev awareness or payment?

They’re making app more modular.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Nick Johnson

Ryan Zurrer

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '22': { - 'Name': 'Nick Johnson', - 'How do you handle smart contract verification and security?': '

Write a spec and define edge cases and corner cases

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

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

ENS: documentation, smart contracts, UI’s,

Auditing other smart contracts

Other smart contracts

Ether cards

Offchain: dev tool, EVM static analysis tool,

', - 'What are the tools/libraries/frameworks you use?': '

Open Zeppelin tools are increasingly good. But try to keep the smart contracts as small as possible

Just web3 itself in terms of javascript

ETH Gas station and etherscan are useful for different reasons

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

Truffle unit testing with mocha

Added built in testrpc

Testrpc still doesn’t have big number support for certain signatures so we have to fire up a geth node

', - 'What tools don’t exist at the moment?': '

Byzantium added return data size (prevents arbitrary return data size limits). Once solidity implements this, it will be possible to return strings and stuff.

Automated updatable smart contract?

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Becoming familiar with the execution model

You don’t store the results on the blockchain, you store the invocations (because the computer is entirely deterministic)

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '23': { - 'Name': 'Elena Nadolinski', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Documentation

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': '

Use Truffle because it’s by far the best framework for testing. Used Embark and Biddler, used Remix a bit for debugging things in memory. Memory explorer would be fascinating. In Solidity everything is a hash table. No case at all for catching hash collisions.

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

', - 'What are your biggest frustrations?': '

Lack of error messages, since Solidity 24 you can add messages. But it’s not backwards compatible. More visibility on what failed and where, that would be extremely helpful.

Do your own Metamask. As your client you don’t have to run your own Node, but want a way to abstract that. Don’t have to rely heavily on Metamask. People get confused on why you need Metamask.

', - 'How do you handle testing?': '

Truffle for testing. Force people to do TTD in events!

Truffle is not efficient in deploying things, can have a deployer contract that handles with more gas efficiency.

', - 'What tools don’t exist at the moment?': '

A lot of tools exist but aren’t being utilized here. There’s no reason that Travis can’t run with Truffle. But this pattern doesn’t exist. Now that we have upgradeable contracts we can think of smart contracts like regular development.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

It’s a myth for how hard it is. “I’m a Solidity developer” is associated with something difficult, but a smart contract is just a piece of code. Once that clicks it’s easier.

', - 'What are you most excited about in the short term?': '

Quitting her job to start her own project so very excited about that. Excited to explore privacy in tech. Crypto is binary, either it fades aways or takes over the world!

Scalability and stability are covered. But not a lot of people are focusing on privacy. Monero and Zcash and explore others, but they’re pretty slow.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Christopher Gewecke, Wyvern team

', - 'What are the best educational resources?': '

Personally found a couple Medium articles here and there, Medium article on how to do your own ERC20 coin in 60 minutes or so. Had to Google a lot.

Good article on NFT’s, read the docs website for Solidity. For a beginner it’s hard

Various projects have good resources, Dharma has a good walkthrough. Collateralize an NFT, you have a loan on a CryptoKitty. Walks a beginner through step-by-step.

CryptoZombies is really good. They do a really good job. They move very quickly into advanced topics.

', - 'Are there any other questions we should be asking?': '

Real world companies that are not tech savvy could benefit from blockchain. Want to sell art to the blockchain, that’s a day project. Squarespace or Wix for dApps. Patterns are so common. If we want to make blockchain more widely used, make this drag and drop and easy. Abstract that away.

' - }, - '24': { - 'Name': 'Swaroop', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

We are building EthVigil an API gateway to to help developers build apps on blockchain without worrying about nodes or RPC calls. We take any smart contract and turn it into a REST interface. Use a modified ERC20 token (and a hacked Remix IDE). So you don’t have to worry about encoding it, filling out strings, etc. Deploy it to a testnet. Even take care of issues that could occur on the blockchain.

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.

', - 'What are the tools/libraries/frameworks you use?': '

Mostly custom tools. Started with web3, started with Truffle but was running into a lot trouble using them so rolled their own.

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

Basic unit tests, integration testing. So much of the codebase that keeps changing so difficult to stay on top of testing, but have must stricter tests on mainnet. At the moment don’t have external auditing.

', - 'What tools don’t exist at the moment?': '

Web3 is a library to make it easier for a lot of developers in the space. But we use JSON RPC calls directly, don’t want to abstract on top of this so don’t want to get anything in between this. Had some issues with web3py.

Recommend that our customers use Truffle, Ganache, etc.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

The first thing I built was a tool that looks for any ERC20 transfer automatically. Built in one month. Not just writing code but understanding the Ethereum paradigm. But I’m not a finance guy or trader so wasn’t super excited about this.

Current error codes are not that useful. Getting a response back saying 0x from JSON RPC for some very weird reasons, but doesn’t handle errors in a great way. Better error codes. Wanted to jokingly call themselve the 0x company but it was already taken.

Lack of documentation, but it has improved a lot..

Dealing with the clients themselves, not using Infura. When you use clients directly and bypass Infura it can be painful to get things running.

There’s no flow at all really. I would randomly learn a bunch of things but nothing flowed together. I bought Ether but didn’t need it to actually build on the blockchain. Ropsten was down all the time. Did our stuff on other Testnets.

Maybe we need to have a flow of learning the fundamentals. It’s all out there but it’s not connected.

', - 'What are you most excited about in the short term?': '

We built a platform to help people use blockchain but people don’t know what they can build on blockchain. We think Digital Assets are the next big thing, CryptoKitties are the first step in showing the world what they can do.

They are setting up their company in the old way, but can do stuff on Ethereum. Writing stock on the blockchain could be a gamechanger. Document signing.

I hope the scaling issue will be solved soon.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Barely anything with tutorials when they got started. He gave his cofounder a crash course in a couple days, and then his cofounder went off and did a self-study. Some good videos were out there (Udemy?) that they bought. But the best thing is to do it on your own, especially because they are operating on a lower level.

Recommend to go to Ethereum main’s website but not friendly enough for beginner to intermediate developer. But this is a paradigm change, completely different way of doing things. Have to educate the developers.

', - 'Are there any other questions we should be asking?': null - }, - '25': { - 'Name': 'Alex Beregszazzi & Pawel Bylica', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Pawel - focused on VM in general, spent a lot of time designing / optimizing the EVM for the future.

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).

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Communication is bad within EF and within ecosystem in general

People aren’t aware of existing products / solutions

Duplicate effort solving the same problems

Not everyone agrees on the same communication channels –

People use different tools

Seems to be fixed now with Gitter.

Lack of resources

People jumping across projects

Workflow on EVM / eWASM – problems (below):

Axic: Review process

On Solidity – we’ve grown 200%

Some people are remote; a lot are part-time

There’s a lot of onboarding

Because of onboarding – not everyone’s review is equal, takes some people with experience and insight.

It’s very easy to block people

Github Projects kinda helped this process:

Organize features into versions.

They had a label for breaking changes;

Should be clear from the PR list.

Backlog is really large and growing. There’s too much that we don’t have enough time to get setup project management process.

For every PR, someone has to learn all the subsystems that are involved. Solidity is a big codebase.

It’s a complicated codebase; needs refactoring

Three ways of generating bytecode from AST:

Way 1: cpp stream of instructions, values, and comments

Way 2: append inline assembly

Way 3: compile Julia into bytecode

Our focus is moving to Julia, and using that to generate bytecode.

We’ve planned a full rewrite of the “code generator” subsection.

But they found a way to do it without a full rewrite.

Julia:

Has an internal AST, a parser, a syntax for the parser.

Backends: which generate bytecode from the AST->EVM, EVM15, eWASM.

Transformation steps: things that happen on the AST; could be built independently.

These exist for EVM and EVM15.

Building these for eWASM could be a task.

But they’re good on-boarding work for new contributors.

The external static analyzer:

Written in Javascript.

Currently part of Remix.

Try to use a number of options that the compiler gives you.

There’s no option to turn off warnings.

Therefore: anything there is a warning, you should fix it.

Delegating warning generation for things that are conventions to this external static analyzer.

Two major things to be done for bounties re the static analyzer:

Bounty #1) Separate it from Remix, and make it independent.

Bounty #2) It uses the old AST format, that the compiler used to generate.

In other words: the compiler parses, creates an AST (which is a big JSON object), which is then passed to the static analyzer

The new AST JSON is much more compact –– but means that the static analyzer should be written.

This could be more iterative.

Mist has this notion that it has Solidity compilation built-in.

Considers “warnings” and “errors” the same –– so throws.

The homepage has 1) old Solidity examples (which has errors), 2) recommends Mist (which throws errors for warnings).

Pawel:

Making cpp-ethereum more modular.

Started removing some parts, and moving it to different repos.

Two things:

A Proxy for JSON RPC.

Maybe should write the Proxy in Go.

What it is:

Previously, we had 1) an HTTP server to handle the requests, and 2) some Unix sockets to handle other incoming requests.

The HTTP server is replaced by a simple Python script. Replaced the HTTP requests with a Unix socket requests, so same underlying system can be used.

There’s no reason for implementing all the transport layers in each client.

This Python script only exists in cpp-ethereum, but should be included in other clients.

Only complaint about Python: it’s hard to ship an executable object of code.

A proxy for the p2p network stack

Same as above, but for the networking layer.

E.g. devp2p or libp2p protocols.

Your application protocol (e.g. Ethereum or Swarm) connects to a new p2p layer.

We should instead use the same p2p layer.

Problem: duplicated effort of implementing the same things.

Need a nice interface for inter-process communication.

Can combine different parts of the stack in different languages.

EVM-C: C interface for EVM.

Should stay under Pawel’s control.

Potential bounties: create EVM-C bindings for different languages.

E.g. Python, Go.

Could be useful to have a fast EVM implementation;

Same idea for eWASM:

Use the same interface within go-ethereum to hook in eWASM.

Other bounties?

Research for opcode gas costs

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '26': { - 'Name': 'Christian Reitwiessner', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Gas profiling:

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Tell us more about computational scalability on SNARKs, STARKs, Truebit?

Research on SNARKs implementation – ZoKrates project. Only a PhD student right now – Jacob.

A toolchain for creating ZkSNARK-enabled smart contract

Need help there, and can pay $ for it.

Why they haven’t focused on getting more people, is the project management burden there.

What kind of help we need:

Implementation.

The project is a compiler that takes a high-level language, turns it into an arithmetic circuit. It’s PoC stage right now. Also needs help with the direction the project needs to go. Needs an evaluation of use-cases.

Also needs people with cryptography backgrounds who can implement efficient arithmetic circuit gadgets.

Someone who can deal with Rust as a language; finite-fields.

Open-source on Github.

Potential help: university research partners –– Dan Boneh?

It’s early, PoC stage. –– currently the elliptic curve pre-compiles are too pricy.

The first step is to see how much it costs, and if it’s feasible because of this.

Analyze use-cases, and see whether its not too expensive.

Improve the trusted setup experience.

Solidity?

Development resources: we’re pretty much good right now.

We have issues marked: “good first task” or “help needed” – these are good to pick up by external contributors. They’re small in scope, so maybe doesn’t make sense for large bounties.

Usually someone creates a PR, we have comments, they update the PR, we make comments, then the contributor loses interest.

Maybe: could have a person who is responsible for external contribution across all projects?

Another project: analyze external contributions, and understand why they weren’t completed. What was missing in the description / what was the issue? If you’re creating an issue for external contributors, what is the detail / info you need so it gets picked up.

Where we need help:

External people to translate the documentation.

This is a big effort. Requires management. Need to keep translation up to date.

This doesn’t really exist right now. Only have a Russian / Spanish translation that are old and rudimentary.

There’s people to do the translation –– need someone to do the project management.

More feedback from people who try out the most recent version of Solidity before it is released.

Before – Remix was set to the most recent development snapshot. Now it’s set to latest stable, so don’t get immediate feedback.

Truffle and etc only upgrade manually – so its more stable – but slows down the feedback / dev cycle.

How would this work:

“Reminder: people please try out new versions.”

Way to give feedback exists: creating an issue on Github OR their Gitter channel.

Most people can’t use the latest the version – because the toolset doesn’t allow it.

As part of the CI, we’re running some tests with specific libraries.

Possible solution:

People submit their contracts to Solidity team.

They get integrated into their CI pipeline – every time a new version is pushed, their contract tests are run.

We get contacted if tests pass re new version working.

Tools for developing Solidity

It’s written in cpp, we usually cmake toolchain for building, cpp-ethereum for semantic tests; thinking about switching to their own interpreter to speed up tests.

Uses cpp-ethereum with a few extra RPC endpoints. Let’s you rewind the blockchain to a particular block. It’s also allows you to modify the timestamp in the next block.

They’re standardizing these API endpoints. -> include ganache-cli in these discussions?

Ganache needs to have this ability.

Having a testing only Ethereum blockchain

Has a memory-only blockchain; is mainly meant to run tests on smart contracts.

Similar to ganache; but performance could be improved?

Ganache has a UI

To improve: high-throughput, many txes at once.

Notes on IULIA:

Compilation from IULIA to EVM is finished.

Optimizer is 90% finished.

This is why the ABIcoder isn’t out yet, because it depends on the optimizer.

Big remaining chunk of work:

Writing code generator to go from Solidity to IULIA – this is in solc.

A year away.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '27': { - 'Name': 'Fabian Vogelsteller', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Need good IDEs:

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '28': { - 'Name': 'Hudson Jameson', - 'How do you handle smart contract verification and security?': '

Use the Remix tool to just scan for general bugs.

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.

', - 'Other bounties?': '

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.

', - 'Who are you and what are you working on?': '

Mainly focused on solidity smart contracts. A little node JS and Java but not very good at it.

', - 'What are the tools/libraries/frameworks you use?': '

Remix, MyEtherWallet, MetaMask

', - 'What are your biggest frustrations?': '

Hard to read error messages. Solidity and EVM might fix this with error messages.

Are you running into problems with any of the following:

Gas limit: Totally. If you don’t properly separate your contracts or import too many, the gas limit blocks you. Especially on Ropsten with a dynamic gas limit, this doesn’t work.

Off-chain computation: Many things can’t be done until TrueBit becomes a real thing. Biggest one being stuff like Plasma and side chains aren’t possible until TrueBit is ready.

State Channels: Haven’t worked with them personally but understand them and think they’re cool.

', - 'How do you handle testing?': '

Have been using Truffle more lately but was mostly just using Remix before.

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.

', - 'What tools don’t exist at the moment?': '

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

The resources are pretty spread out, and everything moves so fast it’s hard to keep up today. If you’re using resources from 6 months ago they might be wildly out of date.

Andreas Olafson had the only videos and tutorials on solidity, so I just watched those to learn.

', - 'What are you most excited about in the short term?': '

Casper. It’s already kind of going into testing.

TrueBit near the top of the list because it has so much potential.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Raine Revere from ShapeShift

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '29': { - 'Name': 'Martin Swende', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

I was a security professional, doing consulting, came into Ethereum a couple of years ago solving bounties for VMs.

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Definitely a need for more developers, either full time or for some scoped project. And not just people wanting to work on ethereum-js!!

Proper debugger would be easy enough to scope out. Built into geth VM, a standardised debugger with hooks so that it can be hooked to FireFox debugger etc.

Network visualisation analysis tool is also very NB.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '30': { - 'Name': 'Kevin Owocki', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Gitcoin X EthPrize

More talent than fundable issues right now at Gitcoin - always looking for more cool stuff for the community to work on.

Happy to help.

', - 'Who are you and what are you working on?': '

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

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

Pytests with TravisCi

Using product. Use gitcoin to build gitcoin.

Selenium tests with native web3 functionality

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Onboarding users with first time Dapp user experience like metamask, mainet/testnet really sucks and could be improved in a number of ways.

We started off chain, since standard bounties is not something we wanted user to pay gas for

What we’d like to do on-chain

Start work feature signal in off-chain DB

Would be stored on-chain

Staking process for starting work on a particular bounty

What features from web dev background are lacking with Dapp Development?

We’ve struggled with managing gas fees on behalf of users

Built gitcoin.co/gas for scraping EthGasStation for least amount of gas + low confirmation time.

Would be nice to visually see gas price vs confirmation time.

Would’ve been nice to integrate gas manager with block explorer, more dapp UI’s

Easy javascript widget to take place of metamask to not hinder gitcoin developers by requiring chrome download. Web2 payments to Web3 payments bridge to abstract away the harder blockchain concepts. Maybe an e-commerce-like widget for paying for gas via CC.

Portis might be like this?

Stablecoins and improved UI’s

Selenium integration tests with native web3 functionality

You can work with DOM on Selenium but you can’t hookup chrome extension (Metamask)

Might be possible with JS widgets

https://github.com/ethereum/EIPs/issues/948 Subscriptions on the blockchain would be great

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Below links, youtube videos

https://gitcoin.co/help

https://www.youtube.com/watch?v=cZZMDOrIo2k

https://github.com/gitcoinco/gitcoinco/issues/38

General help content writing

', - 'Are there any other questions we should be asking?': null - }, - '31': { - 'Name': 'Quazia & RJ', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

A solid debugger – needs a rare breed of dev to build.

Scaffolding tool for prototyping things –

To test a small contract before integrating with everything else.

Think this will standardize over time.

', - 'Who are you and what are you working on?': '

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”.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

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.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '32': { - 'Name': 'Griff Green', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Scaling proof-of-authority.

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Irregularity of gas price.

Key management - hands down stopping adoption. Need more people teaching about key management. Tutorial materials? Bounty?

Ropsten testnet gas limit.

', - 'How do you handle testing?': '

We lean on the community a lot and give them “sneak previews”. We let them to go through the UX, and watch what happens.

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.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

What was the first thing you built related to Ethereum?

Built a Will contract. Got a Masters degree in Digital Currency.

Alex van de Sande took the time to correct his code on Reddit.

Talking about price makes people act like assholes.

The DAO!!

', - 'What was the hardest part about learning to develop with Ethereum?': '

Lack of sharing and communication. I know other people are using React, building UI and that we could re-use that.

How to go from web3 to the UI. Could do more research to re-use existing open-source tooling.

In the beginning we were purely running on the blockchain as a db. Then, their UX suffered due to slowness. Feathers helps alleviates this.

We are a holocratic org. We work in small teams, building the GivEth Galaxy.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Taylor and Hendry from myetherwallet

Dave Appleton

Jack from Colony

District0x crew

Swarm City - Bernd Lapp

Khosla

Nick Johnson

Jorge Izquierdo

Jordi Baylina

Phil Dian

Matthew Diafrante

Karl Floersch

Emin Gun Surrer

MakerDAO - Andy

David Knott - Plasma

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

What other projects do you interact with the most? Building the Ethereum topology, who works with who and which projects? Where there are chasms, so you can get bridge them. Maybe a bounty?

There’s so much good stuff on people’s githubs.

How do you know where to find stuff.

“Sort all Ethereum projects that are using React” -- aggregation of data. How can we get this data into searchable formats?

' - }, - '33': { - 'Name': 'Jordi Baylina', - 'How do you handle smart contract verification and security?': '

It’s important to communicate to everyone that whatever you do will help, but will never give a warranty that there won’t be an error.

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Debugger

The debugger is still hard –– you have to learn crazy tricks to be able to do it faster.

Return codes

When a function reverts, you want to know why it reverted.

Code coverage

Truffle has something, but it’s specific to truffle.

I’d like these tools to be more generic.

Truffle that works for larger projects

Across multiple repositories. You want the contract repo to be able to publish it’s interface, and another repo can use that to interact with it, etc.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Where do you think improvements can be made?

before we can really go mainstream:

Scalability.

Security.

Usability

Seems like security is as much an education problem, as tooling. Any ideas how we should approach this?

Documentation helps.

Realize that you will spend proportion of 40-to-1 on testing/auditing your contract vs writing.

Team audits

Doing an audit within your team.

Once you’ve done your personal work on the smart contract, and you’ve done your own audit; then get together with your team, and start talking about your concerns, and you’ll see that one idea leads to another, and you discover issues.

Audits

Write some small bugs in the code, and see if the code reviewers find that bug.

Even if the auditor knows that there are bugs, they will be forced to go deeper into the code.

Bug bounties.

I was skeptical of these at first. Why would people review this code?

But I have seen personally over the last year that big security holes have been discovered in bug bounties.

Bug bounties force you to write very good code.

You need to choose the right names for variables, document it, it needs to be understandable.

Good resource: Consensys, on the history of all bugs. https://github.com/ConsenSys/smart-contract-best-practices

This wiki could be complemented with these more generic ideas – around bug bounties, reference smart contracts etc.

Maybe even write a book around it. An open-source book.

Smart contract developers could do an annual event – to categorize all the new bugs, new patterns – and consolidate them into the knowledge base.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '34': { - 'Name': 'Stefan George', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Bounties are great for small problems, but we need to hire people full time to actually work on this stuff constantly and fix the long term incentives!!

Just waiting for the Ethereum Query Language ;) :p

', - 'Who are you and what are you working on?': '

CTO of Gnosis and is building a prediction market, ddex and smart contract wallets.

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Secondary indexing of blockchain data!!

Only json-rpc calls to retrieve prediction market data would make it impossible for users to see what markets they hold tokens on.

Expose state changes between blocks in an easy to consume fashion. Right now you apply txes, but you don’t know what effect on the state is immediately. You have to assume that you know, or listen to events.

But events shouldn’t even be there as they are just replication of info that is already there on the chain - just make that info more accessible and easy to read and use!!

State changes between blocks, sort of like a github diff that you can take and use to index in a secondary indexer - that would be really helpful.

Writing their own indexer specifically for prediction markets. So is Aragon, and even Augur is now doing it.

More client developers - too few people working down there in the protocols. Set incentives for improving the stuff - which is why ETHPrize is so important.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

What does the Gnosis stack look like?

Contracts written in solidity

Many pitfalls, especially for newcomers - need to read documentation 10 times and then sometimes you still don’t get it.

For e.g. the low-level stuff like .call() is implemented differently from what you might expect that caused funds to get stuck in multisig contracts.

The concept of gas is not that easy to understand and is not transparent.

If you use .send() you use minimum amount of gas versus .call() using all the gas.

Verification of code and garbage handling is not well documented - verifying down in the byte code is very difficult.

Particular problem for symbolic execution and all the additional checks that solidity is doing. Not well optimized at all.

If you access a storage variable twice, you will always have to pay twice, rather than optimizing to keep it in memory - very annoying in the end. Means you have to do a lot of gas optimisations yourself which really should be automatic.

These kind of issues require domain expertise - why don’t we all put up a $1 million bounty for a new smart contract language/compiler.[a]

Might be interesting to keep it lower level, something similar to Vyper with the much simpler bytecode and cheaper execution, better verification etc. We cannot have only one smart contract language.

Using truffle framework because it is most used framework and want their codebase to be as approachable as possible.

Debugging is an absolute pain in the ass - even truffle’s debugger is not great. No easy breakpoints, difficult to step through easily, or change variable to run different kinds of tests.

Would be better to statically typed testing environment - only test framework in JS (python one is not maintained). We need another framework that can go deeper and be more precise.

Web3 itself really sucks.

API versioning for ethereum json-rpc stuff. No versioning, no documentation, no proper error codes. Plenty of useful calls that are missing, plenty of calls that exist that no-one uses and it’s just chaos in general. We have to assume what version is running on the user end, so have to assume they are running all kind of different versions.

Everyone using MetaMask and Infura makes this slightly more hidden.

I proposed a new json rpc call but geth ahd already implemented it, but it was documented nowhere and Parity hadn’t really thought of doing it at the time, so there is no clear way of defining what the standard is.

Was about allowing users to sign offline transactions in a specific way: ask the client to sign and return the tx data that can be then used from an offline location.

We need a test suite against the json-rpc API: just to test that Geth and Parity are actually behaving in the same way.

Using Remix IDE - then go to local text editors for further dev once they are sure the contracts run well.

Would be amazing to have a properly integrated environment. Uses Atom with solidity linter. Would be great to be able to do proper debugging in that environment as well. Things work now because complexity is relatively small - but as soon as you want to integrate between projects it becomes a total mess.

Gas metering and fuzz testing in addition to break points, stepping through, and changing variables easily.

Use Mythril to check smart contract security, executions and test coverage. Aim for 100% code coverage and use solc code coverage.

Would love a tool with some basic checks (like overflows etc), but needs to be extended to do optimisations for gas efficiency, standard way to apply smart contract best practices automatically.

Map test coverage to code execution paths so that you can easily see which cases to write tests for. Something better than code coverage which only shows where you touch the line so that we can cover the most important scenarios (i.e. where things are failing).

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '35': { - 'Name': 'Alex Leverington', - 'How do you handle smart contract verification and security?': '

It would be nice if some of the audits were completely opened up – rather than some statement from the auditors. Could be a security issue.

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Can’t say what I’ve working on in a concrete way, but I am building a team and starting a new project.

I’m advising some projects.

Did some original stuff on the P2P system.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

Haven’t come across any tools for game-theoretical stuff.

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.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Debugging Solidity and EVM

Robust distributed system for content delivery.

Swarm and IPFS are both in Proof-of-Concept form.

IPFS is minimally viable when you use gateways. But there’s potential for improvement

I haven’t used either in a while –– but my understanding is:

Swarm is a little slow

IPFS is ok –– but you need the client software to run multiple p2p nodes.

All the demonstrations use HTTP gateways –– there aren’t tools and packaging for having production software on the p2p protocol.

Integration should be in the offchain code.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Ambisafe - Olekseii.

Lunyr - they’ve been kind’ve ahead of the curve in implementing things.

I advise them.

They & cryptokitties have production code on mainnet.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '36': { - 'Name': 'Alex Miller', - 'How do you handle smart contract verification and security?': '

Hasn’t had any novel code that needed security audits before

There are common patterns that could be detected. E.g. reentrancy attacks, etc

', - 'Other bounties?': '

Collecting logs & events used to be hard. Web3 1.0 made this a lot easier. It is quite good, even-though it’s in beta.

People should be using websocket calls more. Maybe more education around this. Serious efficiency gains to be had here.

', - 'Who are you and what are you working on?': '

Started ETH development back in 2015. Shortly after launch; there was nothing. I remember booting up private chains from shell scripts. We’ve come a long way in terms of dev tools. Problem isn’t that there aren’t tools, but not knowing where to look.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

Biggest pain points: a place where all these tools get published that isn’t just Github.

Is the solution to hire / pay people to manage a wiki?

Maybe a better solution would be to fork NpmJS.com, source that data, curate that list for Ethereum dev tools

Would check that deployment to node packages happened & EthereumPM setup correctly.

Can see how many people have downloaded. It’s a good method of discovery.

Could have different subsections e.g. Merkle tools, hashing tools, ABI encoders.

I use Ethereumjs-util – but I know there are others.

What about EthPM?

It’s only on Ropsten. What is the link between EthPM and the actual blockchain? I like that there is an actual package manager. Good thing is that you can install packages with Truffle.

I don’t get where the data is stored –– is it on IPFS? Is it linked to Ropsten? Why?!

Still, it’s great. But recently it stopped working.

I wanted to deploy a trustless-relay – but had issues.

Could make one of these Awesome-Ethereum Github repos?

Also knowing what you need to discover is important: wiki would help here.

', - 'How do you handle testing?': '

Use Mocha; plain old truffle tests.

I don’t do contract unit tests.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Truffle

The fact that you don’t really get errors, or more specifically stack traces. Whenever you run into an error, it gives you a line number[c].

In JS files.

How to match up hashes of data with what you get in Solidity.

e.g. When you’re tightly packing arguments, they need to be left-padded to 32 bytes. But not always, e.g. different for addresses and numbers.

A little app like this for Solidity would be amazing, which gives you all the Solidity hashes: https://emn178.github.io/online-tools/md4.html

Emulate what’s happening in Solidity in the browser.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Sean Pollock.

Mark Beylin.

Goncalo (from Consensys audit) -> has a great library for dealing with bytes (byteslib).

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '37': { - 'Name': 'Dave Appleton', - 'How do you handle smart contract verification and security?': '

Helps that I’ve been coding for a helluva long time.

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Lead blockchain dev @ HelloGold.

Token backed by gold.

Does consulting as well – writing smart contracts & backend for blockchain projects

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

About a year ago, it was ok running blockchain on your machine.

Switched from geth ropsten to Parity.

It’s hard to run a Parity node now – the toll it takes on your machine.

Both on mainnet and testnet.

You can’t do serious stuff with Infura:

e.g. getting events reliably

In Geth or Parity you can do some event filtering, but is tough to get right and maintain

Infura limits the number of logging or block calls -> to limit server complexity or costs.

Debugger

Ethercamp

Promote hackathons.

Ethereum Studio - what happened to it?

Gave you break points in Solidity code (?!)

You’re running in a simulated VM. You’re in your own dev environment.

Let you see all the state and local variables & methods

Came up with a node that EF took over and turned into EthereumJ

Ethercamp code is open-source -> Look into this…

I use Remix for prototyping something.

Will probably be a niche product.. Because not many developers are getting that low level.

Web3.js is another pain point:

Getting up to speed trying to do Web3.js is quite hard. There’s a lot of conflicting information. The examples don’t work. This is where you find that the node you’re using doesn’t support features.

Go-ethereum wrapper: abigen. This is my favorite tool.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Programming languages: Go

Compiled program with strong type checking, before the code even runs.

Enforces code standards, meaning your code is maintainable.

The linter formats the code in a certain way. This makes it very easy to understand.

I choose readability over speed; Go over Rust.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Talk to Andreas to get to people in Singapore.

Rick Bale @ The team at Endorse.io

Or also talk to the CTO.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '38': { - 'Name': 'Peter Kieltyka', - 'How do you handle smart contract verification and security?': '

Obviously security audits, looking through network and past experienced colleagues. Don’t see us using formal verification unless that process is made easy, but I don’t think that will happen. We will stick to security audits. Thoughtful in how things fit together and are secure.

', - 'Other bounties?': '

Gas profiler 100%.

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.

', - 'Who are you and what are you working on?': '

Started Horizon Blockchain games, building decentralized multiplayer games. What we’re excited about is a new class of video games, in which players truly own in game items. Own them, and can trade them. They can even compete cryptographically to earn/unlock new items.

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.

', - 'What are the tools/libraries/frameworks you use?': '

We’ve built a blockchain gaming architecture with a low fungibility token, similar to ERC 721. We built our own state channels. We’ve also created offchain game logic, and can verify the game in a single state. Skyweaver.net was our very first game. All work will be open source, won’t do an ICO.

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.

', - 'What are your biggest frustrations?': '

Need more example of really great dApps, more high quality examples. Zeppelin is doing a great job of making a standard library, but more interested in end-to-end. Don’t know of great examples of these high quality dApps.

Scalability is super important, when state channels and plasma channels arrive the whole game changes. Want to see good convergence in state channels, need off-chain computation. Want to see good collaboration here.

Focus more on end-user. Improve onboarding to Crypto.

When people think about scalability, people think about throughput and performance. But cost is integral to this. But what is the transaction cost. Optimizing for cost is a form of scalability.

', - 'How do you handle testing?': '

Do it in Typescript with Ethers.js and Chai and Mocha. Use Remix Solidity IDE. Amazing IDE for testing little blocks of code. Testing would be another great things to see more examples of Ethers.js

', - 'What tools don’t exist at the moment?': '

Profiler at ETHDenver, to see gas costs.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Wrapping your head around the architecture. Very multidisciplinary. And the tooling is in flux. Lack of examples. Architectural issues. Costs are fundamental thing.

Ethereum coding is really like developing for an embedded system with little memory, storage, and cpu power. Unfortunately don\'t encourage beginner to be writing this stuff. But getting better.

Try to map existing architectures to existing things that people knew about. Realizing how everything fits.

', - 'What are you most excited about in the short term?': '

Blockchain video games.

Very excited about Casper+sharding. The team is doing incredible work.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Richard Moore,

CTO of Dencentraland. Esteban Ordano. Great guy, very knowledgeable.

Liam Horn, should pick his brain. Very hands on in Solidity.

', - 'What are the best educational resources?': '

Point them at Blockgeeks, all about Blockchain development education on Ethereum. Plus searching Twitter and Github, look for those great open source dApps out there. Look for examples of end-to-end dApps

CryptoZombies created a rad Ethereum tutorial.

', - 'Are there any other questions we should be asking?': '

AwesomeList, community curated high quality tools. Ethereum website needs to be completely redone. Here are the awesome projects, here are the awesome tools, here’s how to get started. Same with website work.

Exactly Ethereum Foundations problem, do not want to make any opinions that aren’t in community consensus. People voting for what they want worked on. People can vote on things. Certain weight to reputation. Consensus machine to conduct this type of thing.

With a footnote, don’t need to perfect this system. Don’t need a perfect design to start.

' - }, - '39': { - 'Name': 'James Prestwich', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Simple contracts to manage cross-chain swaps and contracts.

', - 'What are the tools/libraries/frameworks you use?': '

Python ETH Library - ABI Parsing expects events to be in two different formats neither of which you expect - ecosystem standardizes on hex strings

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)

', - 'What are your biggest frustrations?': '

Solidity is the wrong tool. Imperative language and everything on blockchain is declarative. Solidity should be declarative.

IVY is best example of for blockchain language. On blockchain control logic is impossible: blockchain never decides how or when a function is called. No such thing as on-chain control logic: off-chain controls how humans can manipulate state.

All lies: completely wrong tool for blockchain. This is what causes render mistakes: trying to write on-chain what happens, but should be defining what can/can not happen (Bitcoin: whether you can or cannot spend a UTXO).

Require statements example of Solidity becoming declarative language is not a good way to fix this and modifiers are an anti-pattern:

Either happens as atomic single unit at will of human or it doesn’t?

Configurable constraints on-chain: we should still define them as constraints -- no math happens on-chain (not actually adding 2+2 on chain).

Weird that tests are control logic for your code. Control logic is whether human makes a transaction.

Idea that we are writing things that add variables on-chain is wrong.

Reality of state, state root and blockheader is what causes a lot of the bugs

IVY: really heavy modification to write on ETH -- more easy to write languages for the EVM. A declarative language for EVM. Tooling for Solidity only recently got workable.

Onchain systems should define constraints around what cser can / cannot do -- they are the control logic of the program.

Cross chain contracts for integral is what users can and cannot do at what time and on what chain (declarative programming again).

Checks, Effect, Interactions to write code. We need more good programming to prevent race conditions, re-entrancy, double spend etc:

Transactions happen atomically, cant have overlap in state changes

Can shoe horn ETH into this by using Require / IF Statements (??)

Avoid modifiers as a pattern

That’s always the effect of the Solidity you’re writing - puts more pressure on the client

Makes testing more intuitive -- specified tests you’re testing against

Very interesting miner attack on EtherDelta: they front-run; make tx throw; collect the fees.

The problem with Solidity isn’t expressiveness; it is shared state. Other transactions can get ahead of you and modify state that you rely on.

', - 'How do you handle testing?': '

Wrote tests with James on Integral stuff

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Proof of Stake

Getting someone slashed decreases supply, increasing value of ETH. Does this mean every ETH holder is incentivized to getting stakers slashed?

In the Blockchain/cryptography in general, there is attack-defense asymmetry with defence being stronger. As soon as you move towards servers, attack-defence asymmetry leans towards the attacker.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Did all the Ethereum tutorials -- set up the token

Integral: written in Solidity with Truffle -- derivatives platform

', - 'Are there any other questions we should be asking?': null - }, - '40': { - 'Name': 'João Gabriel Carvalho', - 'How do you handle smart contract verification and security?': '

Every project I’ve done will go through an external audit. As a developer, usually run Mythril and Remix (uses Oyente?). But these only find basic bugs, are years away from more complex stuff. These are just the most basic checks.

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.

', - 'Other bounties?': '

A really good IDE.Not a plug-in, but a full IDE. Best elements of Truffle, best elements of Remix. Could connect to Geth. More refined deployment options. Make compiling easy, knowing the gas prices easier. Debugging, deploying. Everything in one place.

', - 'Who are you and what are you working on?': '

Contributed to OpenZeppelin and Aragon about 1.5 years ago, met an audit company called Solidify. Worked with them as a developer, and also have done a lot of audits securing smart contracts, now back to development. Things happening that will be public soon, stay tuned!

', - 'What are the tools/libraries/frameworks you use?': '

Truffle.

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.

', - 'What are your biggest frustrations?': '

A really good IDE. The integration between Truffle and Remix is not good at all. Remix debugger is better than Truffle but painful to upload a bunch of stuff to Remix just to check. Wish there was a way to integrate both tools.

A more robust testing framework for Truffle, it’s very basic and dumb if you think about it. A lot of room for improving testing tools.

The issue is that I don’t have functions to hit a contract with 1000 transactions, I have to do it manually. Create me 200 tokens and send to this contract and see how it behaves. Tests are small scale. Testing suite at scale could be interesting.

More state management in testing. Want to save specific states and fork it and compare it to the fork. A lot easier and automatic.

10 accounts are provided with 100 ETH. That’s not enough to test an ICO like condition. If he wants to test 100 accounts with 1 million Ether, it’s not easy.

', - 'How do you handle testing?': '

Do it manually, 1000 accounts with 1000 Ether. A big loop and keep sending transactions

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.

', - 'What tools don’t exist at the moment?': '

Love to see a premium version of Infura. Infura is public nodes. Has to sign tx’s offline, has to sync my own Geth. I wans to have an Infura account. Infura is pretty good here but could be a bit better.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Hidden barrier for understanding blockchain in general. Could be a decent developer, but to understand Ethereum you have to understand what is a blockchain, how does it work. And you can’t learn this in a day, there are complicated concepts that you have to learn with time. Have to really know what a blockchain is to develop a contract that makes sense.

Have to do a lot of handwork that you don’t do in other languages. There are no error messages. Have to comment your code and run it a thousand times to see how it’s failing.

', - 'What are you most excited about in the short term?': '

Excited to see where all the scaling is going. Plasma, Casper. Starting to get implemented and finalized, can see demos. That’s awesome.

Excited for proof of stake. To see how the ecosystem changes.

Interested to see how average user interacts with Ethereum. UI/UX.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

CryptoZombies is pretty good for a beginner. Capture the Ether is a bit more focused on security and hacks. The best thing to learn more is to read contracts. You can understand a lot of how big projects work and it’s very good for learning.

OpenZeppelin is a good place to start, has day 1 level stuff. Gnosis has a lot of well-written contracts, a bit more advanced. Same for Aragon, complex but it’s well-done. These are the ones I’m more familiar with.

', - 'Are there any other questions we should be asking?': null - }, - '41': { - 'Name': 'Andreas Wallendahl', - 'How do you handle smart contract verification and security?': '

Also Josh Cassidy

', - 'Other bounties?': '

In-browser signing. Would make new user onboarding much, much easier. Metamask works on it but a bounty might drive it through.

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': '

Truffle

Geth nodes on Google Cloud

Eth.js

React

', - 'What are your biggest frustrations?': '

Helping a user know what to sign and what it actually means at the blockchain level.

If new user comes to your website without Metamask, they can’t interact with any web3 on your page.

Gitcoin uses a faucet to get around this

Onboarding experience

Most users are devs so they understand it better than most

Internal Consensys initiative started to onboard new users

', - 'How do you handle testing?': '

Needs to ask teammate (Josh Cassidy)

', - 'What tools don’t exist at the moment?': '

Simple spin up of side-chain or scaling solution kind of like Heroku

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Hardest part was not knowing where to go in the beginning. Watching videos to understand concepts of blockchain. From there, Truffle and its intro tutorials.

Everyone was rebuilding the same stuff/components for public apps and enterprise use case.

', - 'What are you most excited about in the short term?': '

Anything people can experiment with, and that can prove interest/demand.

NFT’s, Ujo and Cryptokitties.

Blockchain’s version of single sign on. Store user information in some way (IPFS or UPort contract)

How do we get to 1,000,000 daily users

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Sam Smith, reputation AI at Consensys

Josh Cassidy

Michael Cena

Sarah Baker Mills (designer)

', - 'What are the best educational resources?': '

Cryptozombies - the more modules the better

Chainshot - like codecademy, checks with unit tests

https://github.com/ConsenSysLabs/ethereum-developer-tools-list/pulls

https://medium.com/covee-network/here-are-the-best-courses-and-resources-for-learning-solidity-ethereum-dapps-600e18287381

https://medium.com/bcgdv-engineering/getting-started-with-ethereum-as-a-developer-af20d78c49f

https://medium.com/@wslyvh/getting-started-with-ethereum-solidity-geth-part-2-d195144fe6c7

Cryptomechanics.info

Consensysacademy for a full course

https://t.co/aRO7B8z50h

', - 'Are there any other questions we should be asking?': null - }, - '42': { - 'Name': 'Clement Lesaege and Nico Wagner', - 'How do you handle smart contract verification and security?': '

Write our own functional tests - but don’t provide proper security against malicious actor (can’t simulate those kind of network conditions easily). This is where fuzzing would be really, really useful. Try to understand how contracts could be exploited in ways that the developers can’t directly specify in tests.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Working on dispute resolution through smart contracts

Arbitration - process to decide who is right/wrong. Looks more like an arbitration DAO - system of incentives.

Enforcement

Decision-making

Incentivising people

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

We REALLY need a very good web3 tool that is actually stable - the errors returned through the json-rpc are impossible to decode and find info on. Making this library more performant is a key issue.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

A tool to analyse security of smart contracts better, especially complex smart contract suites. Very excited to see formal verification, whenever that comes out.

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.

', - 'Other domain specific questions?': '

Pre-interview review from Nico:

It would be great to have a language like python, C to build smart contract to avoid learning a new syntax even if the syntax solidity language is good like the viper project (https://github.com/ethereum/vyper). The developers lose time to learn it.

To have a js tool to communicate with the node it is very stable and useful. We have encountered many problems with the web3 library. The library https://github.com/ethereum/web3.js/ (0.14.0):

dependencies installation sometimes broke

use callback (promise is much better)

callback to know if a tx is mined break sometimes

So we choose to use ethjs.js instead of this tool. Apparently this has been fixed recently in version 1.0. But I haven’t tested it yet.

An easy tool to make a hash with a salt. It’s very difficult (for me) to find a library/hash function with the same hash than ethereum even more when there is a salt (https://gist.github.com/f43d7807b69402060dd6e4c8db730afc.git)

A boilerplate to build a dapp like http://truffleframework.com/boxes/. The last time I tested this tool it was very unstable, so we prefer to build our own boilerplate .https://github.com/kleros/dapper. A very good tool like this can be very useful for the developers to easily build a dapp with all tools to communicate with the ethereum protocol.

A tool to sync the front-end state with the ethereum state like drizzle http://truffleframework.com/docs/drizzle/getting-started

I haven\'t tested this tool yet but I was told it was unstable.

Truffle doesn’t support the last solidity compiler (0.4.22)

', - 'What was the hardest part about learning to develop with Ethereum?': '

Building safe smart contracts takes a lot of experience and understanding of game theory, cryptography, complexity skills and an insight into the edge cases that can be used to exploit certain patterns and implementations.

There is no single point to learn about all these domains, so it can be really challenging to get exposure to all of the required fields, and eve to realise that these fields are important to writing good SCs.

', - 'What are you most excited about in the short term?': '

Decentraland rocks!!

0x

Truebit

Proof of Stake in general will be very important going forward. In fact, everything that allows for scalability and lower tx fees with higher tps is absolutely critical.

IPFS is interesting too - right now they are hosting some part of the website/DApp themselves and that constitutes a central point of failure, so easy-to-use and maintain decentralized storage would be really, really great.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Github and Reddit are the most useful.

r/ethereum sometimes has posts with a lot of documentation and that is almost always a great place to start.

Trawling through GH issues looking for the comment that leads you in the right direction.

Readthedocs is also super useful - esp for Truffle and Solidity.

Can be very fragmented - there are a lot of sources and some are out of date etc. Not necessarily too bad to have a lot of sources as Google can generally lead you to the right place.

GitHub should be the hub for developer documentation particularly.

When I can’t find a solution, just googling is always very helpful. Sounds cliched, but someone else has almost definitely had that problem before. This often leads to a gitter conversation and the dev channels there tend to be fairly responsible.

', - 'Are there any other questions we should be asking?': null - }, - '43': { - 'Name': 'Dan Tsui', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

LLC that does consulting and builds projects

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

There’s the inner crew of devs; then there’s other teams who are trying to build stuff, but who don’t have the same access. There’s also language barriers etc.

We don’t quite know the lay of the land: e.g. “should we integrate with Metamask or build our own things”?

Knowledge of tooling and documentation –– very fragmented / scattered across ecosystem.

How to incorporate layer 2 solutions?

People’s roadmaps are defined based on their analysis of tech at the time of their ICO, even though new stuff is becoming possible nearly every day. Staying up to date with this is challenging.

When we were starting work on Ethereum stuff we needed to learn. In order to do that well, we needed to talk to different projects as this is ultimately the best way to learn and the Ethereum community can be very welcoming if you just find the right channels.

But how do people know what to use who aren’t in the community: e.g. Metamask vs Mist?

Dfinity asked them to go through all the Ethereum dev tools

They use truffle, ganache, Remix - all the usual stuff.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

GK Chan - jchan@kyokan.io

Matt Slipper - mslipper@kyokan.io - wrote UI’s integrating with Metamask & leading Spankchain wallet project

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '44': { - 'Name': 'Jacky & Matthew', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Matthew:

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

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Plasma: the future is close – will see this live in 3-6 months.

Generalized state channels: L4 and Spankchain.

Plasma Cash:

The idea of a coin that you sign over to different parties – it’s kind of like a cheque.

Can replace other entrenches business –

Can attach it to a stablecoin.

In-browser Ethereum light-client: Mascara.

We’re in the internet before packet-switching.

After that, everything is open and possible.

Can integrate cryptocurrency with your everyday life.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '45': { - 'Name': 'Andrey Petrov', - 'How do you handle smart contract verification and security?': '

Write a lot of tests myself. Get other people to read it. Keep it as simple as I humanly can.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

https://thousandetherhomepage.com/

', - 'What are the tools/libraries/frameworks you use?': '

Truffle - not his favourite, but best thing out there right now

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.

', - 'What are your biggest frustrations?': '

Dapps: web3js stuff sucks. In the doc, it’s in a weird halfway state where its deprecated but there’s nothing superseding it. Its pretty broken in many ways. At least 4 solutions that are about 80% done.

(ethers.js, but it doesn’t speak well to metamask. Fixed now 11/05/2018)

UX stuff?

CryptoKitties situation - lot of people want a basic way to swap a transaction with one with higher fees. That’s kind of an ethereum specific thing.

Scaling?

Lightmode thing with Geth - a lot of users use the lightmode. In terms of scaling user base, that’s relevant. Eventually most users use lightmode, and right now its broken. [Related update: https://vipnode.org/]

Spinning up more nodes is useful!

(Campaign to show selfies with your nodes, every office should have a node or many, etc.)

Are you running into problems with any of the following:

Gas limit

Probably a truffle problem: it returns a lot of errors related to the gas limit, but they are not actually errors. Error messages are probably just not great.

Better errors on the gas limit would be useful to address underlying problem.

Off-chain computation

Been thinking about some game ideas, and a lot of them require off-chain computation.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

Things I want improved with truffle: it has a lot of moving pieces. Reliant on the nodejs ecosystem and all that. Would like to see a binary runner - want to be able to have a binary, give it some solidity, and it knows how to run it in a simulated environment. Really useful for deploying continuous integration and stuff.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

A lot of tooling that isn’t there. Ecosystem is “bursty”: there was a big burst of dev for web3, but then it stopped, it’s not done, and it’s not advancing. Truffle seems to be same thing. Why? Well people build the stuff they need, and then they stop building.

Operational security of the thing. Easiest way to use it right now is to install metamask, which is not great. If you install ina browser with other extensions, its as secure as other extensions. Installing mist is not happening. Sure it says write down seed so it’s safe, but doesn’t explain full meaning or ramifications of that.

Do better about default backup practices. There could be automatic backup processes.

Biggest risk is loss, not theft

', - 'What are you most excited about in the short term?': '

What dev tools on near horizon that would change things?

Web 3 stuff is almost there but not quite

Need to look more into the ZK stuff which is cool, but needs more researchers on it.

Tons of room improvement for wallets

Mobile dapps are in the VERY early stage. Mobile wallets that can run dapps are just reaching market.

Status

Ethers wallet has it

Metamask for brave mobile

Cipher

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Max Veytsman

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '46': { - 'Name': 'Liam Horne', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Co-founder of L4 and Counterfactual.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Better UI testing. Would be awesome to have am MetaMask mock - wanna launch Chrome Canary, Safari, Moz and ganache will auto inject into the page some provider that could be used to test the full flow. We have also started work on this.

We need more to more people working on ethers.js!!

It is the best library out there, especially for quick operations, and we need like 5 more people at least working on it,

Web3 is too opinionated about exact use cases, whereas ethers is much more generic and simple and can have a lot of tools built on top of it.

We have been hesitant to develop non JS stuff, and haven’t yet because there is no ether.js equivalent. If there were an ethers equivalent in Rust that would be awesome.

In terms of solidity: ABI encode and decode (not written well yet, but will be super useful) are really game changing! It should be 0.3 or 0.4 or something!

Really bad documentation, especially around nuances to do with memory or storage objects etc.

When things happen in solidity, what you can do with it is not explained well.

For instance, one thing you can do is now use returndatasize to get the output bytes from some call you make. The minimum amount of code you need is a few lines of assembly.

However, this is not well known or used.

Our whole system is based on off-chain contract, and the rules in there need to be enforced by on-chain contracts. So I need to be able to interpret arbitrary function calls based on arbitrary logic/user input. This is very hard…

We do conditional payments, and these ensure that a bunch of things are true, and then interpret the results of a bunch of functions and then take those outputs and pay people. All of these inputs, not contracts, and it gets complicated.

There is a specific error called unimplemented_error which comes up in a few cases. The only way to figure this out is to google it and there are 3 or 4 options to pick from, which seems sloppy.

Error messages could be much more specific about WHAT is unimplemented.

Would be great to see also in the docs WHY certain things are not yet implemented.

There’s some subtleties around exactly how libraries work in solidity. Will send through more details when editing.

Would be nice to have a debug mode for events, so that they will trigger regardless of whether or not there was an error so that we can use that as a console.og

Also, there should just be a console.log ;)

If you emit an event with a dynamic struct and pass it a dynamic struct, the whole thing doesn’t make it back in the logs: it only shows the top of the event. It certainly doesn’t show the whole thing.

Whenever you hit gasLimits, you should be able to find out easily where it stopped and what line it is stopping at.

Better documentation on the assembly command sand specific example usage of them would be really good.

Breakpoints with context - these are the variables and scope etc. I will sometimes play around with delegatecall and then I don’t even know which context I am in anymore and this can block me for extended periods of time.

There’s a bunch of sneaky tactics: like keyless signatures. There is a way to generate a sig for an exact and specific kind of tx from an account whose nonce is 0, because then the create opcode gives back a deterministic address.

Please can we document this!? There should be a person on stuff who just plays around with this stuff and then documents it.

This is very serious stuff, if there were a keyless-sig library, so many other things would also be available.

Better google results for Ethereum!

More literature on how Ethereum can be used to do the things people think other blockchains are better at.

Highlight ethresear.ch and some post sthere, like one from Vitalik about businesses paying gas fees for their uses, which is EOS’ biggest argument.

Even worse, explaining plasma, where it should be feasible to have no fees at all.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

WASM is likely most useful for us medium term.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': '

Ethers.js. Really, it is super simple to use.

', - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

I just read the code, man. What is the latest commit by ChrisEth on solidity? That is the best source.

Otherwise, Richard Moore knows everything. Literally.

', - 'Are there any other questions we should be asking?': '

It would be interesting to have a meta bounty for the most valuable stack overflow answers and that person gets a 1ETH reward.

If that became a really legit place that people in the community took seriously, that would be really great and of high value.

Getting a good mod on staff to manage this and then put it out!

' - }, - '47': { - 'Name': 'Richard Moore', - 'How do you handle smart contract verification and security?': '

Extensive testing!

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': null, - 'What are the tools/libraries/frameworks you use?': '

I use all my own stuff, mainly

Ethers.js

ethers.cli

Ethers.build

Parity

Node.js

', - 'What are your biggest frustrations?': '

Documentation is a huge problem

A lot of documentation is simply missing, or its not good

It’s all outdated! It seems authoritative, but then I find it’s wrong. People don’t always do a good job of this. Ethers is only non-solidity implementation of solidity’s S3 that works correctly.

If you read the docs, it’s just wrong!!

', - 'How do you handle testing?': '

Automated testing? How do the facilitate manual testing?

Ethers.build

Automated

Also facilitates manual testing

Rudimentary debugging

', - 'What tools don’t exist at the moment?': '

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]

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Install and setup and configure and run and sync your own chain is ridiculous.

Libraries like web3 which have big problems.

Web3 feels weird given how javascript is used and behaves.

What would be the hardest part of teaching somebody to build a dapp?

Mainly just the idea of how blockchains work. People tend to misunderstand what the blockchain part can and should do.

It’s very easy for a person to write a terrible contract. Even if you write a terrible MVP, it’s easy to release the non-terrible version later. But with this, if you make a bad mistake, it’s a huge problem - more like hardware, you can’t always change it on the fly.

And the documentation sucks.

', - 'What are you most excited about in the short term?': '

0x is cool. Rufflet is neat! I like the idea of having introspection tools in the system.

Also: https://www.withpragma.com/logging/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d

Debuggers are super important and I want them! Martin Swende demoed one, but needs some other stuff… his thing focuses on monitoring the EVM code and state changes its performing, as opposed to solidity. I want to be able to step through my solidity code line by line and see the changes that it is making on the blockchain.

The sourcemap is not super reliable. Because once you compile, it might reorder operations, and certain ops span lines, it starts becoming non-obvious what the correct thing to point to is.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Yuet Loo

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '48': { - 'Name': 'James Childs-Maidment', - 'How do you handle smart contract verification and security?': '

No process, but would love to have it.

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

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

The tools are pretty early. Constantly running into a ton of bugs.

On Leeroy, had to install packages and fix stuff from other projects that were broken so he could use them.

Yesterday was playing around with a new app, and was using Ganache, and it would just lock up and crash. Then you need to redeploy the local smart contracts, which takes about a minute to get up and running again.

A really stable local chain would be cool.

With solidity, it would be great if you could get a better view of what went wrong when a transaction fails.

', - 'How do you handle testing?': '

Truffle for testing (JS unit tests).

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.

', - 'What tools don’t exist at the moment?': '

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

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Only started in June or so.

Just reading through github and reddit instead of an actual source for education. Having really good docs in one place is a big thing.

', - 'What are you most excited about in the short term?': '

Aragon.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '49': { - 'Name': 'Yondon Fu', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Previously: working on smart contracts.

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Livepeer that runs as Daemon, unlock your wallet, give this an in-memory key. They have a DPoS protocol built-in.

Similar operational problems as someone running a validator node for Casper FFG

How does Daemon have access to private key, in non-manual confirmation from you? How do you do this securely?

What’s the proper key management flow. Not necessarily a bounty, but shared knowledge.

Need better documentation

Some of the new things you need to use are not documented yet. Writing documentation is a good way to introduce someone to internals of a project (they need to understand stuff to write the docs).

Example: heard this from Eric at Livepeer, there’s a tool in Geth called Pupeth: uses Docker containers to set up an Ethereum private network, gives you dashboard - would be awesome.

libp2p (networking layer for IPFS) especially since it’s gaining a lot of adoption but the examples for getting started are still a little sparse

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Smart contracts:

Contract compilation time is slow. We use Truffle compilation, which I thinks uses Javascript-bindings for C++ compiler.

Sometimes the compilation takes longer than the tests.

Running C++ compiler (solc) without the Javascript binding is way faster.

Can Truffle use the Solidity compiler internally, without the JS binding?

Maybe this is an easy feature add[a].

I’ve played with DappHub. It’s much faster.

It would also be helpful to specify a compiler version to use without using a completely different version of Truffle

If you make a change, Truffle tries to be smart about which contracts to recompile. Sometimes this doesn’t work and you need to blow away /build dir and recompile. Not a great UX.

In ‘truffle console’: using JS promises are annoying –– can be verbose and hard to read.

Would be cool: having a transformation of that console, if it had async/await, or some kind of wrapper to make things seem synchronous.

If I see an error in a contract:

Debugging sucks. Right now: comment out code, recompile, deploy, run again.

Solidity is adding a “reason” string for the revert message. So you can have reasoning!

They have an internal Ethereum testnet running.

Writing the Go client:

Pain point: nonce management –

Options:

Geth web3.sendTransaction: geth sets the nonce for you.

The other option is to pick the nonce yourself.

For our client, we do the nonce management ourselves: there’s a method to get the Nonce, and includes transactions in “pending” state, but you don’t know them if you’re not a miner.

This is an issue if you submit concurrent transactions.

Parity has a custom method called nextNonce, which works properly –

Parity vs. Geth different methods – there’s more room for cross-client feature sharing, adding things into the standard RPC interface.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Guys at Aragon – Jorge or Oliver.

Ethereum Natural Specification style – basically a commenting style that can have auto-generated comments from it. Aragon is building a custom version of this.

Zeppelin.

0x

Been putting out good developer tooling. Really into Typescript, static typing.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Have we considered Grants, for longer-term things, vs. simply bounties?

E.g. Debugger would require longer-term maintenance, needs to develop in pace with Ethereum development. One-time bounty might not be enough.

Might be a fit for longer-term projects. Milestone-based?

Nicola Greco had some interesting ideas about incentivizing more open, collaborative academic research - are there learnings from thinking in this design space that can be applied to general open source?

' - }, - '50': { - 'Name': 'Eric', - 'How do you handle smart contract verification and security?': '

Internal security audits. Taking time to do thorough code reviews.

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.

', - 'Other bounties?': '

Identity solution. ENS exists but like a great solution that’s built on top of ENS doesn’t exist yet. Some solution around there is interesting

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

', - 'Who are you and what are you working on?': '

Been working on Livepeer for 2 years, before this was an entrepreneur. Was interested in Bitcoin in 2015 and saw Ethereum launch in the same summer as Steemit. Those two things got my attention.

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.

', - 'What are the tools/libraries/frameworks you use?': '

Use web3js a lot, we use a lot of peer-to-peer networking in addition. First version of livepeer was a fork of Geth codebase and adding video streaming, since then we have a brand new code base.

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.

', - 'What are your biggest frustrations?': '

When we first started was still pretty hard to write code in Solidity, Truffle was just launched. That was a big hurdle. We operate our own Ethereum test network which has its headaches.

There are quirks in the Ethereum network that are not documented.

The Ethereum network in general does not do event subscription, notifications don’t work great here. Most popular tool is in Infura but their websockets are pretty flaky

We ask people to run Geth lightnodes, these have less overhead than full nodes but are still a bit of overhead.

We found a bug in the code and then did a smart contract upgrade process using a proxy contract pattern which saved us. Upgradeability doesn’t work super well. Doing the upgrade, communicating with the community, etc. was a big undertaking.

', - 'How do you handle testing?': '

Do a lot of unit testing. Try to cover as many cases as possible to make sure the code quality is high. There is not a lot of guarantee in terms of testing for security.

', - 'What tools don’t exist at the moment?': '

Better Debugger comes to mind. Monitoring systems and alerting systems. Metrics gathering systems. No one has figured a great solution for this.

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

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

The amount of technologies you have to be familiar with is much larger than other tech stacks. Security, new programming language, JavaScript to interact with the contracts, game theory, sheer amount of knowledge that you need to get started is quite high.

', - 'What are you most excited about in the short term?': '

Really excited about Casper, gonna be cool to see. Proof of stake at scale. How it affects the economics in the ecosystem.

Some layer 2 solutions that become fully usable. Past theoretics. For POA Network, the explorer is currently not there.

Plasma is longer term. Cosmos is coming online, Ethermint afterwards. Loom network, etc.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

SuperMax Project, protocol explorer for protocols that are living on top of Ethereum. Build for Aragon, CryptoKitties, etc.

Connecting dApp developers to protocol developers. A lot of projects building on top of Ethereum that he knows need both. As of yet unnamed project but will connect.

', - 'What are the best educational resources?': '

Tutorials on Ethereum home page. He always tell people to start working on a pet project and that’s the best way to learn. Instead of going through a tutorial you should think about something cool and that’s simple enough that you can build your own thing.

', - 'Are there any other questions we should be asking?': null - }, - '51': { - 'Name': 'James Duffy', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Some type of tool that would take ETH Smart contracts, pack them up and automatically deploy them to mainnet.

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

', - 'Who are you and what are you working on?': '

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.)

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Deployment is “tough” - initial problem we set out to solve

When first building DAPP, testnets are a mess:

Just don’t work at all - people eating up all the transaction bandwidth or DDOS them.

Faucet to get ETH on testnet is hard to find and use at scale.

Setup local development with Truffle / Ganache, which is fine, but once you want to get it live to demo or do anything really useful, it is quite a headache.

Our CTO just deployed it to testnet, which was less of a headache. However, deployment to mainent itself is quite difficult

ETHDeploy: auto populate wallet with huge amount of Ether; test things without having multiple steps; blockchain clone.

Became less of a focus for us. Doing something with Loom had potentially a much bigger audience and more use cases.

Still need transaction costs on main-net down!

Our argument is that not everything involves high storage of value / sensitive data (doesn’t need full decentralization), but we still want important parts on main-net (character data, owning items)

Delegate Call (first app): users earn karma and tokenized karma they can transfer to mainnet for contributing to site.

Could load cryptokitty into platform (ERC-20 + ERC721)

Storing hashes of large amount of data verifiable on side chain. Mostly using relay to transfer tokenized assets

Limited experience on mobile, which limits user adoption. Steep learning curve there

Metamask is most straightforward thing, but not sure how to improve.

', - 'How do you handle testing?': '

Truffle / Ganache. When it’s time to test on a real network, sometimes just deployed to mainnet .

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

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Loom - tell us more about games on the blockchain

Lots of people working on games and some early successes inspired lots of people.

Games will be first real use case outside of financial payments

In-game assets that you physically own and can trade; real digital scarcity and users running nodes with the power of forking (nodes can reject changes to games) means an entirely new frontier of possibilities. Developers can’t shut down the game!

Shared game worlds because data is open on blockchain

Think it’s going to be easy to gain user adoption with in-house game studio and building three games.

Loom is developing an SDK to the point where it can be packaged and used by public

Games and social apps -- anything could run on these sidechains

Need constant feedback of teams trying to use it, so we can iteratively improve it

Pluggable consensus mechanism.

DPOS that we built in-house (like Steemit type) social sites

We plan to support Casper / Tendermint. Not usable version that’s public, the byzantine fault tolerant mechanism specifically.

Core developers are close 20. Cofounder has done projects at Bloomberg, Digital Ocean, spoke at 20 Go conferences over past couple of years. Friend out of India runs team of senior developers, have had a team there from the get-go.

Not being based in US means cost is much lower

A lot of: senior back-end developers that had worked with distributed systems

1 SDK building in-house; games to demonstrate platform, onboarding game companies (Unity)

Make it easy for normal devs to make the jump into building blockchain dapps!

Core developers at Loom are close 20. Cofounder has done projects at Bloomberg, Digital Ocean, spoke at 20 Go conferences over past couple of years. Friend out of India runs team of senior developers, have had a team there from the get-go.

Not being based in US means cost is much lower

A lot of: senior back-end developers that had worked with distributed systems

1 SDK building in-house; games to demonstrate platform, onboarding game companies (Unity)

Make it easy for normal devs to make the jump into building blockchain dapps!

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '52': { - 'Name': 'Matthew Di Ferrante‏', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Audits

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

How long does it take to setup dev environment & tests.

On my own computer: I don’t use ‘npm install global’ or ‘npm’ at all –– I’ve created my own vagrant script, which specifies where I install stuff.

It takes a long time – 1, 2 hours – to update part of the environment.

It’s a huge barrier to entry

Also, a huge barrier to experimentation.

Making something where you can from idea to execution, would be great.

Remix doesn’t work for complex interactions, or with something that’s already onchain.

Things get truncated in Javascript.

I wrote my own Python stuff – for handling bignum calculations and submitting to the contract.

We need better support for interaction with contracts that have non-trivial inputs:

E.g. if you need to some pre-processing.

Common patterns across projects I’m auditing:

There’s limitations to the Solidity compiler – simple fixes could help the rest of the ecosystem make less mistakes:

E.g. imports:

If you import an interface, then you have to link to a contract onchain. Or you can directly import a contract.

Having a pre-approved list of contracts –– there’s no reason to be redeploying things on the chain.

Ethpm does this – but worth adding support for this in the compiler itself?

People roll their own complex math:

Because Solidity doesn’t have floating point, people come up with binomial approximations etc.

Talk through a complex audit and how the process works:

First: site-read the code.

Notice small details: e.g. there’s an unbounded loop here.

Setup the environment

Actually execute the code.

Step through the code with a debugger:

I use EVMLab – shows opcode per line with the state.

Notes:

I have a lot of hack-ish tools I’ve built himself. Would be nice to standardize these.

For audits: I don’t look at the offchain stuff.

How do I get testnet eth?

On Ropsten: I have a server.

Some clients have their own testnets; I forward through their machines

If I need a lot of testnet eth (eg. testing a reverse dutch auction): I might spin up my own dev net.

Moar?

Having a setup tool, like truffle init, which initializes keystore and an initial chain state where each of those addresses have a balance

You’d run this after ‘npm install’, ‘truffle init’ in your workflow

Going from ‘truffle init’ to a working ethereum setup takes too long

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '53': { - 'Name': 'Jenna Zenk, Travis Jacobs', - 'How do you handle smart contract verification and security?': '

Continuous integration with tests and Oyente integration

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.

', - 'Other bounties?': '

Javascript library and

Light client

', - 'Who are you and what are you working on?': '

Decentralized asset management system. Smart contract that allows you to set up and manage digital assets.

Feature complete protocol going up to mainnet for short period of time for testing.

', - 'What are the tools/libraries/frameworks you use?': '

Smart contract: Dapp by Dapphub. We manage packages with git modules. Includes Solidity compiler.

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.

', - 'What are your biggest frustrations?': '

Coverage tool with truffle worked okay, but nothing available for DApp.

Solidity’s lack of error handling.

Web3.js is far from mature, Eth.js looks okay but not to many people using it. Ethers.js is good for wallet management but a bit monolithic. JS library that will emerge as a standard is the one that maintains it. More functional JS approach from someone who loves Javascript. Event watching, querying blocks.

', - 'How do you handle testing?': '

Use Parity.js for deployment on test network

For testing- use Ava javascript framework

', - 'What tools don’t exist at the moment?': '

Really good .js library, better standard. Our front-end would love to help with ideation/funding.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Light clients

Graph protocol - create a data layer that caches the blockchain that sits between in SQl database.

IPFS, OrbitDB.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Stack Overflow is best for practical development issues

', - 'Are there any other questions we should be asking?': null - }, - '54': { - 'Name': 'Aaron Kumavis', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

We’ve had good experience with bounties – Gitcoin,

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Usability

Challenging because there’s a large range of users.

E.g. Kenny at MakerDao who’s now at RChain. Hiss job was to manage the multisig for their funds. He’s sent a 1000 transactions on Metamask, he’s always signing, approving, etc.

E.g. other people have no idea what’s going on, want to participate in an ICO. Any extra information you give them confuses them.

Toyed around with the idea of presenting two different ideas. Advanced mode.

We have a whole support team.

Some tickets are sophisticated bug reports. Some are “hey, you stole my money”.

We’re trying to build general education resources.

Bounty: Ethereum for dummies.

In Metamask support –

What is a private key, what is a seed phrase (most important!)

Tokens are initially straightforward. But looking at a block explorer, it says my tx was sent somewhere else.

Why do I need to pay ETH to send a token to someone?

Gas prices.

Metamask can share learnings from their support team.

Whymarrh is introduced in contributing few hours.

Thinks videos or walk-through could be the best medium for explaining complex things.

Kauri can have specific documentation for technical stuff.

Transaction confirmations

We need to explain what is happening to our users. The DApp could be lying about what’s happening, which makes it extra complicated/interesting.

Metamask receives a tx from the DApp, but no more info.

How do you convert that into a message to the user?

“It looks like its talking to a token contract; or sending a random blob of data...”

Take that low-level data and have to convey to the user what’s happening.

We have special cases – e.g. a token transfer, this is an ERC721, this is a DAO proposal, etc.

There’s non-normal stuff – e.g. what’s it like for a sidechain?

Multi-network –– how would it work for non-Ethereum stuff?

E.g. secure scuttlebutt.

E.g. Filecoin, Dfinity, etc.

E.g. Plasma chains inside of Ethereum.

Standardization of transactions, blocks, signatures, etc. –– not bounty-able right now. Need to build an architecture around it.

Then, you need plugins, which could be a good fit bounties.

Scaling. We have 1m users...

A lot of the work for scaling has happened inside of Infura.

Part of it is just throwing money on the fire.

They developed a REST api for json rpc. So now they can put a CDN in front of it, and get caching.

But now, a standard provider can’t point at the REST interface.

Seems like the big need is for standardization.

E.g. Maker’s ERC20 version doesn’t match the standard.

That’s not because we don’t have enough conversation, it’s that we don’t have real governance.

Infura is an existential risk for Metamask, because it’s expensive and we’re a non-profit.

We’ve been working for a while on their light-client. We’re blocked by some libp2p internals.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '55': { - 'Name': 'Dan Finlay', - 'How do you handle smart contract verification and security?': '

Regularly TDD. Write a lot of tests. Truffle, dapphub etc.

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.

', - 'Other bounties?': '

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.

', - 'Who are you and what are you working on?': '

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...

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

Test network, mainchain, local test rpc, mocked user interface.

', - 'What tools don’t exist at the moment?': '

The ability to make really lightweight user interfaces that subscribe to blockchain state.

Would prefer that json-rpc return promises.

json-rpc is unperformant, wish it was easier to contribute to.

', - 'Other domain specific questions?': '

EIP-719 would make a great bounty to make this. Contracts exposing a way to request a human readable. render approval screen.

Could make transaction process human readable.

Moonlay by Mist team[a] is interesting and deserves more attention.

Browser permissions. These require browser vendor cooperation. The only way to expose web3 is to require read/write access to all websites. But we actually only want to expose to a few participating websites.

Web3 api

', - 'What was the hardest part about learning to develop with Ethereum?': '

Ultimately these things are not usable yet, because blockchain isn\'t scalable, and blockchain hasn\'t scaled. This is not a pleasant way to build applications.

Also, a lot of patterns aren\'t defined yet.

For example, in CryptoKitties when you lock a kitty, another user might retry kitty.

In general, conveying to the user [who is interacting with a smart contract] what\'s happening under the hood is frustrating.

There is a big chasm between what people are used to with current application and blockchain applications, i.e. things like gas.

Cryptokitties is great example of what developers are capable of creating on the blockchain. Established web design firm. What decisions did they make based on docs?

We need to address what constitutes a production grade app.

Scaling is eventually a part of that. Plasma chain interaction might look like in a web app.

', - 'What are you most excited about in the short term?': '

Looking forward to helping people access funding for opportunity they didn\'t have before.

Non-profit to voluntary social infrastructure, small businesses that would have.

Social token launches. Make it more accessible to launch and sell coins for small businesses.

WeTrust, Bancor, Circles, Curve token issuance, Puddle, Ripple’s trust lines which is getting adopted by Raiden, Open Baazar Trusted, Keyva, Geo, Sherpal, Building Societies.

Also excited about remote keys stored as a service, i.e. some service to store consumer keys.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '56': { - 'Name': 'Christopher Brown', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Full stack web dev, working in finance and some other industries. Started in Eth after reading WSJ after Frontiers release.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

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.

', - 'What tools don’t exist at the moment?': '

The community is doing a good job and a lot of the stuff we need is already being worked on by someone.

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).

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Having a sequential getting started stuff on ethereum.org is totally, absolutely necessary.

List of tools and resources and even an appendix-like structure of what things like Distributed Applications even mean.

Defining use cases for those don’t wanna be in blockchain is still really hard today.

Solidity readthedocs is very good though. Web3 v1 is much better documented too.

There is a disconnect between web3 v1 and latest geth: the way we were fetching tx receipts were not syncing correctly

v1 websockets are still kinda screwy and not handled as well as they need to be.

Ended up putting the service using the node in the same container and just ipc

Resources themselves, you really need to dig for.

Geth has resources that are very outdated and fragmented - please can we fix this!

Not having definitive resources and docs is a big problem in general.

Search github and Reddit to find random answers that I need.

', - 'What are you most excited about in the short term?': '

Proof of Stake overlays will be really interesting! Bring on the FFG!!

Getting WASM out there will be really important (and finding a use case ;) )

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '57': { - 'Name': 'Harry Denley', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Building a platform / website to educate people on how to stay safe. MyCrypto has some stuff.

I have a Twitter poll that described this idea.

Create a bounty around this.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

People too focused on making money and not trying to evolve the society –– moons and lambos rather than lasting change.

What I’m passionate about right now: helping people who are not technologists to not lose their money.

Could make it harder for attackers to withdraw.

Talking to people from Changelly/etc re blacklisting addresses on exchanges.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

I have mostly used Web3.js. It has a great wiki. I haven’t had any real issues.

Then, I went to meetups where I heard of Truffle and Solidity.

Documentation on setting up Testrpc and writing Solidity was not that great. Had trouble with Truffle documentation.

Some dependencies for Truffle and the build they were using were missing.

Integrating Ethereum with browser hasn’t been too troubling.

I look at Etherscan comments + MyCrypto support tickets comments.

Anti-phishing – Etherscan blacklists bad addresses, through their moderation queue and etherscamdb.info reports.

Most people don’t realize a Private Key should stay private

Airdrop sites require you to put in your private keys.

How to prevent phishing:

Metamask added domain blacklisting + my extension.

I plan to do analysis using PrestoDB, finding common outputs across Ethereum phishing addresses. E.g. If most addresses go through Shapeshift, then go through Monero, can then contact Shapeshift to add their blacklists.

Big data requires a beefy server to run it on.

Open-source for big data analysis of chains for fraud. I talked with Chainalysis (they do Bitcoin analysis) about the idea

I haven’t wanted to do this – mainly because of cost & security. I’m looking into servers which could handle rate-limited requests.

Could put this towards the anti-phishing group.

Making the reports public would be simpler and already helpful

Allows me to run Mysql-style queries.

Lack of reliable faucet on testnets.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Quiknode – selling managed Ethereum nodes that are in sync. Bit like Infura.

Adam or Paxon.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '58': { - 'Name': 'Taylor Monahan', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Money is not their constraining resource. People, hiring, management are constraining.

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Silo’s – Slack silos aren’t healthy.

Mentioned “community of communities”

Skype – “exchange work-group” – public infrastructure and the nodes – w/ the geth team and the nodes.

Skype – “anti-phishing group” – setup on a whim when they saw phishing stuff come about.

3 days ago – Ethereum blue team found MyEtherWallet clone

Even if she’s sleeping – people are looking out for the community

Did team retreat in Columbia / met with design firm in Chicago / they have partners in SF (week / month regularly)

Harry Denley was the first to respond to Swarm.city multisig hack.

Was reactionary – putting out fires.

PROBLEMS: Security

Internal security processes.

At two people you can trust each other; access is limited. At team of 20 it’s different; have to revamp internal policies; reminding people of things.

Found 2 Slack admins not have 2fa on.

We are bigger target; we get password resets.

Someone stole her number in October but they were prepared for it. They handled everything really well.

DNS and internal security on infrastructure.

Hired ex-director of security for Coinbase & Facebook. Works on board of Hackerrank.

How we hired: people who use MEW want to keep Ethereum & MEW safe. We connected on security. We had a call that afternoon.

He does amazing security incident response & red-teaming.

FEW DIFFERENT SECURITY CONCERNS:

How we serve their code: a commit is pushed to a specific branch; that is served to github.io; then AWS pulls that code, caches the hell out of it, and that serves MEW.com.

All keys are rotated, and ssh private keys are kept very secret.

multi-stage pipeline (Github + AWS); both have multi-factor security, need Ubikey, etc.

It’s kind of a staging pipeline.

Prevents bad commits or bad UI changes from getting into the website.

How do you QA things, how do you test things?

We wait 24 hours from creating a release and getting it on a live domain.

We have a series of tests – check that everything compiled correctly, check that all links have a rel=no-opener on them, ..

DNS

After EtherDelta and ClassicEtherWallet.

We have a custom thing: three services to monitor the site.

We serve through a CDN

Diff the code – diffs the new website with the previous version of them.

Gets the hash of the Javascript and CSS with previous versions.

Blockchain security

Ensuring the user makes good decisions –– how do you alert or notify a user when is doing something wrong –– e.g. notifies you when an Ethereum address is not formatted correctly?

How do you build this: check the balance?

Have microservices that have micro-databases of the blockchain.

Caching token balances.

On MEW: pulls everything from Parity or Geth directly.

Can run their infra through Cloud Formation ––

Geth falls out of sync.

CryptoKitties destroyed their infrastructure.

Intel chip thing then took them 120% CPU usage, took them offline.

Fixes for Spectre and Meltdown.

PROBLEM: phishing & supporting after the fact.

PROBLEM: infrastructure:

Keeping nodes Parity & Geth up all the time.

Additional issue: Blockchain naturally re-writes itself if you’re on a microfork. If you’re also distributing this across your own database, then you need to write code to also rewrite this. Etherscan just gave up and booted up from the blockchain from scratch.

This is what Infura is trying to do. They are in the same situation as MEW and Etherscan. They are under Consensys so have more financial freedom.

Shapeshift sysadmin stole money. If they had the problem, then this is a big problem.

What is the cost of security in this space? How much a malicious people could stand to gain…

With a debit card, it’s not the same –– there is risk of getting caught, the original person gets the money back etc.

Traditional security systems won’t work for this.

When I worked at AT&T, I asked people how they trained people to not steal simcard numbers. The real cost is not cost of buying a phone.

UNEXPECTED PROBLEM: building remote team culture

I work well remotely; but building culture while remote is really important.

In-person hangouts – all devs will be at EthDenver.

Make them talk about personal stuff on calls.

Big question is to: how to make remote team work.

Danielle leads the dev team.

Over the summer, they did a hire fast fire fast mentality. Sink or swim type of game. People need to be able to orient themselves.

People in the beginning need to be able to make sense of the chaos.

Random people contributing on Slack or Github.

For support, hire top Reddit commenters.

Give people 30 days and see how it goes.

Ethereum Blue: anonymous team, with a token. Promoted themselves as Metamask Blue. Scam.

Teams that are dealing with public crypto token world:

Swarmcity. Super resilient team. First fight against Arcadecity. Then theyy got their funds stolen out of their multisig.

0x. Did an amazing job about education around ICO. Each blog post had a full section on how to protect yourself + custom tools.

Griff

Griff + Hudson Jameson from EF are the people to call. They know everyone and who to get involved. Like a connective tissue. Response to Parity hack.

Griff had learned a lot from the DAO hack.

Hudson was at Cornell with entire EF security – just happened to all be in the same room.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '59': { - 'Name': 'Nate Murray', - 'How do you handle smart contract verification and security?': '

Wish i knew better how to do audits. Would love to know list of auditors. However, even if I could get in touch with auditors it sounds expensive.

Use solc linter when developing.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

I started by creating my own token using the tutorial on Ethereum.org.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Everything seems super easy getting started, especially once you understand how the blockchain works.

Then you learn about security vulnerabilities like re-entrancy, other well known hacks, etc. Developers don\'t think about that when doing web dev.

Newline\'s third class is \'Hack smart contracts\', and it covers DAO hack. The goal is to teach folks about security.

', - 'How do you handle testing?': '

At first, getting contract working use Remix or testing framework built into truffle.

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.

', - 'What tools don’t exist at the moment?': '

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Tutorials are out of date.

API totally changed in web3 beta.

Understanding the Ethereum blockchain & program execution model.

What it means to \'call\' and get (for free) or \'send\' and updating the blockchain for a fee. What it means for you transaction to be mined. This is covered in newline.

If high performance computing today is extremely parallel, then blockchain computing is embarrassingly serial.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Interesting smart contract platforms coming out.

LISK dapps in eos web assembly.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '60': { - 'Name': 'Benjamin Bollen & Paruyr Gevorgyan', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

We are building a developer kit that builds a bridge from Web2 to Web3, nice interface so that people don’t need to have understand blockchain to use it.. Need to get users on the technology.

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.

', - 'What are the tools/libraries/frameworks you use?': '

From an IDE perspective: Tried to use Remix, but not so easy to set up locally. No finalized IDE. It’s powerful but not easy to set up, very complicated to set up and not so stable.

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.

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

Using Truffle. Have a setup where for local dev purposes are tested on one chain. At a later layer they are tested on a testnet.

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.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '61': { - 'Name': 'Fredrik Harrysson', - 'How do you handle smart contract verification and security?': '

Internal audits.

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)

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

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

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

Lack of documentation is a big thing. The deploy/test/repeat cycle is unclear and kind of annoying. It’s a problem of the whole stack, not just certain libraries.

E.g. On top you have the React app, with hot reloading. Super easy.

One level below you have the middleware library. Auto-generated from the ABI, and there’s some other knowledge you need. E.g. Someone clicks and approve button, which changes a contract variable and updates the UI for the owner. The business logic is both in the contract and in the JS middleware, which is hard to deal with.

Layer below that is Node.

IPFS client server, so the client can upload a file.

Hash is stored on chain.

File is stored on IPFS.

Layer below that is the contract. Any changes in the contract bubble up, need to recompile the ABI, need to recompile the middleware from the ABI, need to recompile the React app because the underlying dependencies have changed.

Something that changes the level of abstraction for managing files would be great.

', - 'How do you handle testing?': '

Use truffle internally for testing some contracts

Also write own own testing tools using Rust because we don’t like javascript

', - 'What tools don’t exist at the moment?': '

Setting initial values after deploying a contract is important

Being able to roll back transactions would be really nice for dapps

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

How do you codify the differences between a traditional app and a blockchain app. E.g. Waiting for transaction confirmations. How do you codify it to make a good UX?

' - }, - '62': { - 'Name': 'Nicolay Wolf', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Research for cost of running WASM on different architectures and machines.

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

What is the difference between eWASM and parity-wasm?

Parity works closely with WASM ––

Parity uses the same endianness as EVM. But eWASM uses little-endian / WASM uses little-endian.

How does eWASM callcode, because it depends on hardware architecture?

Parity forbids some useless constructions, e.g. “internal memory” ––

Any WASM module can include private memory; according to wasm-spec it’s not accessible at runtime; Parity forbids this.

Projects working on WASM:

Parity, eWASM, Dfinity, Bitfury

Bitfury has Exonum – solution for enterprise blockchains with WASM runtime.

Higher-level languages: Rust or anything else that compiles into WASM.

They’ll move away from Solidity. – good to have for backward compatibility (so someone making solidity-wasm compiler would be good) but not necessary.

Standardizing WASM implementations:

Can do renames to match eWASM or something like that.

Interoperability amongst WASM implementations:

Will have a simple tool that can compile eWASM to parity-wasm to etc etc.

WASM vs. EVM:

WASM doesn’t force you to use the 256-bit machine.

E.g. if your computations fit 32-bit, you don’t have to deal with this inefficiency.

WASM has strong teams behind it.

They’ve made a bet on WASM; so there will be resources behind it.

Bugs will get fixed by the wider community.

WASM can be targeted by mature languages: c++, Rust, Haskell is coming, etc

Resources:

Who’s working on Parity-wasm:

Nicolay & Sergey.

Nicolay is moving to part-time on this stuff since there’s lots of other work to do.

There will be another meeting about Ethereum sharding & wasm.

Thailand, end of March.

Our libraries:

Parity-wasm: serialization & deserialization library – for changing / transforming the wasm module.

Wasmi: the actual wasm interpreter

https://pepyakin.github.io/wasmi/wasmi/index.html

https://github.com/pepyakin/wasmi

What’s left to do with parity-wasm:

Need good libraries – Rust-specific – to interact with blockchain storage

Solidity gives you this out-of-the-box – but we need to build it for Rust

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '63': { - 'Name': 'Peter Czaban', - 'How do you handle smart contract verification and security?': '

First contracts were usually for prototypes.

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

Definitely the language and tooling. Testing frameworks.

Truffle can be weird and does some asynchronous things that cause tests to randomly fail.

Linking contracts together is still kind of bad.

Are you running into problems with any of the following:

Off-chain computation: Yeah, this can be somewhat difficult. I have seen others not being able to use it, so it clearly needs to be easier.

Could detect patterns in a contract and recommend that something could be done off-chain.

Sometimes you want to have privacy. Solidity and compiler could figure out for you how to make particular mappings anonymous.

State Channels: Played around with a simple one but no serious problems or anything.

', - 'How do you handle testing?': '

Mostly truffle for testing. Also have some of my own custom tooling that works on RPC.

', - 'What tools don’t exist at the moment?': '

Being able to run things in exactly the same environment as the deployment environment (for me, it was necessary to have a custom client that I ran code against)

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!

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

For building the client, it was high-level architecture, but that was resolved just by having lots of conversations with people.

Would be useful to have more documentation around here.

For building with Ethereum, it was Javascript and Truffle, because I already had good understanding of Ethereum at that point.

', - 'What are you most excited about in the short term?': '

From experimental projects, I am interested in prediction markets and how they will work and how good the price discovery is.

A very good application is something that doesn’t require too much throughput. Something around supply chains could be really interesting. Many parties, don’t necessarily trust each other.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Parity guys that work on the UI.

' - }, - '64': { - 'Name': 'Phil Castonguay', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Used to work for 0x, now I work as a SC dev and researcher independently.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

I struggle with fuzzing: it’s very useful for when different people are working on the same standards - so we could easily run fuzzing between entirely different teams and see if the way they implement all the functions behave the same way and make sure the different implementations of the same standard are the same. Better standardisation is key.

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.

', - 'What tools don’t exist at the moment?': '

Nothing exists for state channels regarding how you pass messages and other p2p tools that allow different agents to communicate easily with each other.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Coming from a non web-dev background and more from data analytics meant that everything related to async was difficult to grasp. It’s unintuitive.

Solidity dev is not particularly difficult, but the best practices are extremely important and it is only really by experience that you learn the best and safest patterns. You need to know most edge cases and most potential attacks before you can write contracts that can actually be used.

Reading about past exploits really helps. Ethernauts is really great.

Each opcode and how much gas it costs - there are tables online, but not updated and it takes some time to search properly the Yellow Paper. In fact, anything related to code optimisation could be really cool to see.

Educational content focussed on code optimisation. Has not seen as much of it as he has of security and both are equally important. I.e. “Try to rewrite this contract in under 5000 gas” kind of thing. Who can achieve this, this and this with the least amount of gas.

Now implemented: https://g.solidity.cc/

', - 'What are you most excited about in the short term?': '

95% of the projects are not ready for the mainstream. Mass adoption necessarily requires state channels or plasma, or secondary consensus layer like a sidechain - so that is where we really need the most development as soon as possible.

Loom network etc. is also really exciting.

Sharding comes later, and is really exciting, but the stuff above needs to happen first.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Mostly about tools and enhancing developers lives. Finding information and answers is also really important, so ask more about the docs if you can.

' - }, - '65': { - 'Name': 'Federico & Jaynti', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Trying to work on Plasma – white paper is unspecified; it is not clear yet.

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Websocket isn’t there. It’s not customized. Interface is not that good in geth or parity.

I used to have my own servers running – my own laptop as a node – very painful, switched to Infura.

Crawling Infura.

Infura is unreliable – sometimes they miss the blockhash.

Why not run my own node?

Too costly to run Digital Ocean.

Web3.js – nobody can use it well; very flaky. Talked to Fabian about it and offered help.

People are using, but not contributing.

UI/UX:

Everything takes time; 15 seconds; 1 minute for confirmation. People are impatient.

Wait for notifications using Dagger.

How to improve:

PoS will improve this finality. Still too long for users.

Provide a notification to users; or email if it’s about security. If you’re buying cryptokitties, can send a follow-up email.

EthAlarm used by Decentraland –

Status building decentralized notification system.

Fede has been contributing to Solidity compiler itself for over a year now:

Mostly making the experience of working with Solidity more pleasant. Life is too short.

Solidity is quite understaffed –– only two people who are committing, who can merge PRs.

Fund more developers?

I’ve contributed, but would love to get paid for it[a][b].

Not many people have the availability to take part-time or full-time work at EF (Solidity, Truffle, etc etc). But are available for several hours a week to contribute.

Promote the people contributing -> funding.

EF has Dev Grants. Mostly geared towards bigger projects. E.g. porting Ethereum to mobile devices and wearables.

Also Scalability grants.

Ongoing funding to ongoing contributor would be interesting.

Better communications -> what different teams are building right now. e.g. with Plasma; there’s different people around the world pushing forward different implementations.

Weekly core developers meeting – where one can participate. But how to scale that? Need different structure. There’s multiple different teams. There’s also the Gitter channels. There’s ethereum.research forums; that’s helped communications in research and fundamental infra problems.

There’s an issue of time; the valuable people don’t have the time to work on these things.

Someone watching all sources and compiles them into one place: so more people know what to work on. Proof of Work newsletter (WeekInEthereum?).

The fragility of Solidity tools – lack of proper tooling; e.g. comparing language ecosystem between Java and Solidity:

Linters, refactoring code, working with modules, ...

Debugging

This improved recently:

Latest truffle version includes an embedded debugger.

Daphubb working on new EVM with debugger built in.

Gas issues: we sent multiple wrong calls to wrong deployed functions – wasted lot of money

It doesn’t tell you why your gas is so high – it doesn’t say that you have a weird opcode

People don’t understand what is gasPrice and gasLimit properly.

Allow people to set one value – and set gasPrice and gasLimit interactively in the backend.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Patricio Paladino from Zeppelin.

' - }, - '66': { - 'Name': 'Alex Leishman', - 'How do you handle smart contract verification and security?': '

We refer companies to trail of bits/ other.

Formal verification handled by specialized firms. Important contracts will/should be audited by people.

', - 'Other bounties?': '

Large players funding bug bounties for public smart contracts.

Multisig is a pain in Ethereum. Multiparty signature with a single key from an account.

', - 'Who are you and what are you working on?': '

I am an engineer on the Polychain team, but come from the Bitcoin world. Used to work at a brokerage. Went back to grad school. Decent amount of experience in Bitcoin and Ethereum stuff over the years. I also have a cryptography background.

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.

', - 'What are the tools/libraries/frameworks you use?': '

I don’t do much eth-dev right now.

', - 'What are your biggest frustrations?': '

Expenses when running contracts

', - 'How do you handle testing?': '

CI pipeline needed.

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.

', - 'What tools don’t exist at the moment?': '

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

How to apply Ethereum tech and what makes sense.

', - 'What are you most excited about in the short term?': '

Lightning - cheap, fast micropayments even though it’s not out of beta.

Ethereum bindings for lightning network?

Cross-chain stuff in general.

', - 'Was anything easier than expected?': '

Wallets UX has improved.

', - 'Who are the other people you think we should talk to?': '

Trail of Bits

', - 'What are the best educational resources?': '

Andreas’ books

Ethereum wiki on Github

', - 'Are there any other questions we should be asking?': null - }, - '67': { - 'Name': 'John Palmer', - 'How do you handle smart contract verification and security?': '

Linting

Code review on my own and with other people. Check best practices from Consensys

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Web applications that interact with smart contracts, usually through MetaMask or Infura.

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.

', - 'What are the tools/libraries/frameworks you use?': '

Web3.js

0x.js

Truffle

Testrpc

Infura

Remix Solidity

Etherscan

', - 'What are your biggest frustrations?': '

The smoothest user experience happens with MetaMask, but MetaMask has tons of bugs. Regularly need to disable/re-enable MetaMask. Causes a lot of headaches because there is a lot unexpected behavior.

', - 'How do you handle testing?': '

First of all, I write unit tests in javascript and run those locally.

Interact with smart contract through remix solidity or Pragma.

Test my app in my own UI. Check etherscan to make sure that happened.

', - 'What tools don’t exist at the moment?': '

It’s not possible to bundle two different transactions together and pay with them at the same time with MetaMask.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Biggest pain point was learning Solidity. Not knowing how everything executed.

Not as easy to write something and test it right away, longer feedback loop.

Solidity documentation was out of date.

What would be the hardest part of teaching somebody to build a dapp?

Explaining the difference between wallets and contracts, and explaining to them the concept of Gas and how that dictates what they can store in their contract. Explaining how computation works on the network.

', - 'What are you most excited about in the short term?': '

Would be really excited to have a mobile metamask. Wallet Connect seems promising on that front.

Seeing Dapps do live token swaps using 0x (functionally exchanging coins in an application). For example, being able to swap tokens in a game.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Antonio Juliano

Nick Johnson

' - }, - '68': { - 'Name': 'Marcus Molchany', - 'How do you handle smart contract verification and security?': '

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

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

', - 'What are the tools/libraries/frameworks you use?': '

Ethereum: Remix solidity, testrpc, truffle, web3 JS, Infura, Etherscan

Web: React / redux, create-react-app

', - 'What are your biggest frustrations?': '

In general project setup for the first time is difficult.

Didn’t know if I needed geth or testrpc.

Didn’t know if I needed to download the entire blockchain.

Also had problems with the documentation for solidity.

', - 'How do you handle testing?': '

For contracts, I use Remix Solidity with the Javascript VM. For unit tests, I write JS unit tests using truffle. Tried to write unit tests in solidity but it was difficult. Testrpc behaves strangely sometimes.

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.

', - 'What tools don’t exist at the moment?': '

I really want a richer debugger. The one in remix is too hard to figure out[a].

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Slight paradigm shift about waiting for code to be run while transactions are mined.

Understanding how state was preserved in a contract.

Finding good teaching resources on Youtube and elsewhere.

What would be the hardest part of teaching somebody to build a dapp?

The paradigm itself.

The idea that when your code runs, it’s running when a block is mined.

Calls to your contract don’t execute instantly like in a normal web app.

Combination of needing to use different test nets while testing.

', - 'What are you most excited about in the short term?': '

More 0x relays!

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Fabio Berger from the 0x team

' - }, - '69': { - 'Name': 'Piper Merriam', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

The Hive tests –

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Package management:

First piece: the spec

ERC whatever that defines the spec –– this is v1.

https://github.com/ethpm/ethpm-spec

There is very minor adoption of this.

There is a v2 of this spec –– couple of tweaks to fix stuff that was wrong in the first one. This is mostly written up, needs PRs to be written and merged.

Second piece: the implementation.

There is an early Python implementation –

https://github.com/pipermerriam/py-ethpm

but you need this in every language.

Needs various abstractions, for how to get deployed contracts –– returns language-specific object to you.

Third piece: a standard –– an ERC for package registries.

https://github.com/ethpm/ethpm-spec/issues/75

Standard methods for looking up what versions of the package exist, what is the hash / IPFS / HTTP URI.

Fourth piece: implementation of the registry as a smart contract.

There’s an already implementation of this in the EthPM github. Needs to be simplified.

https://github.com/ethpm/escape/blob/master/contracts/PackageIndex.sol

Having this in Zeppelin or Dapphub.

The fifth piece: can have tooling + ENS nicencess to automatically deploy to registry for you.

Web3.js and Web3.py can implement methods to talk to packages –– can find the packages, pull them, use the right abstractions.

e.g. you load up the Gnosis package, pull the latest version, pull it out of your web3.py, and query for your contract balance.

Theoretical API: `web3.packaging.registry(‘packages.gnosis.eth’).loadPackage(‘gnt>=1.2.3’).contracts.gnt`

You get a really secure way of accessing contracts

Each company can create their own registry.

What do you need?

Two moderately skilled Python devs who know about Ethereum.

Two can keep each other in check – it’s healthier.

Could have MVP for this in Web3.py in 2-3 months. For the full thing. Could have an alpha release.

What does wider adoption look like?

Every etherscan contract can be wrapped up in a package.

At this point Etherscan becomes a package registry.

Verifying package source on Etherscan becomes trivial –– you upload a package to Etherscan.

No more need for janky copy-pasting source code.

Wallet interfaces:

MyEtherWallet –– instead of having address or ABI, you can upload the package or let you browse the registry and pick a package to interact with it.

Mist Ethereum wallet –– “track this contract” –– can show you a thing on the top that says you’re not using the latest version of this package. You get a security bonus –– to notice if you’re using an old package.

Development framework use-case for packaging!

Is the one that’s most talked about, but is probably the last one that will happen. It requires complex integration between compiler and on-chain assets that might be stateful.

The base libraries however are needed as a stepping stone to build these features on top of.

NOTE:

Piper can lead defining this as a bounty and setting the milestones.

$50k/$60k feels like enough to attract attention. Can potentially get ETH foundation to fund part of the bounty.

Web3.py

Been using Gitcoin pretty heavily –– has been highly effective. Any task that they can define well, they can get done through Gitcoin reliably.

Trinity –– Python Ethereum node

Some use-cases will be greatly improved by third-party libraries

There is a solid abstraction around the database.

Generating a SQL backed chain db would hugely help research.

Take an existing chain db and migrate it into a SQL db. Or just sync the chain into SQL.

Maybe you only move the transaction and block data into the SQL db.

Another use-case for Trinity:

Spin it up on Heroku – it’s an ephemeral environment – for that to be a viable way to run your own Ethereum node.

Issue: how long does it take to initialize. In its lightest light-client mode, should be ready in sub-1 minute timeline.

Trinity and PyEVM have the most resources available out of the things they’re working on.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '70': { - 'Name': 'Richard Ma & Don Ho', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

IDEs:

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

', - 'Who are you and what are you working on?': '

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

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Running the client:

Language support across different clients is problematic. We’ve been focused on the software verification libraries for now.

', - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

NuCypher.

Keep network.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '71': { - 'Name': 'Jay Rush', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

The tracing API across the two clients is different and seems ad-hoc.

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.

', - 'Who are you and what are you working on?': '

QuickBlocks works with the Ethereum blockchain from the data side. How does one get usable, fast data out of the blockchain (as opposed to putting into the blockchain with a smart contract for example). Our work is fully decentralized (gets all of its data directly and only from the node); We take a bottom-up approach. We run for particular accounts or groups of account, not necessarily chain-wide. We retrieve and store only what the end user asks for.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Biggest concern: The idea of decentralization is being lost

People are developing applications that are highly centralized, because it’s practical. Many projects promise they will one day decentralize, but I’m concerned that this will get increasingly more difficult as the technical debt grows. Many projects are deeply relient on highly centralized infrastructure (Infura, EtherScan).

Concern: The law of unintended consequences:

Identification Systems

Ease of use is very enticing

Blockchain based identity is easily applicable for government use

But...what happens when a “bad-actor” government or an oppressive regime requires citizens to all have unforgeable identity. How will innocent people who are legitimately against the regime hide themselves?

I wrote about this here.

Reputation Systems

If we move to a world where everyone has an immutable reputation--by definition half of the population will always have a worse reputation than the other half. Due to the nature of feedback loops, this feels like a bad idea.

Concern: The data is too difficult to use

Per Account Lists of Transactions:

Accounting for both incoming and outgoing external transactions is easy. Just scan to and from fields looking for a given address.

Accounting for outgoing message calls (Etherscan calls these internal transactions) is also pretty easy. The smart contract itself initiated the message call -- send an event.

Accounting for incoming internal transactions is very difficult. One must look at every message call generated by the entire system to fully account for all incoming internal transactions (witness air drops). I wrote about this here.

Bloom filters:

Every transaction receipt has a logsBloom field. These are ‘rolled up’ into the block level. Blocks also have a logsBloom field.

As the number of transactions per block increases (as it has done), the block-level bloom filters are getting more and more saturated. As they become more saturated, they will tend to report more false positives.

At the receipt level, the logsBloom are probably under-utilized (that is, they could hold more information without a large increase in false positive rate).

These two factors tend to make the logsBloom field both less effective than it could be and at the same time require more storage than they need to.

I wrote about this here.

Furthermore, the bloom filters exclude certain ‘addresses’ that, if they were included, would allow us to implement an RPC entry point called ‘eth_listAddressesInBlock(bn)’. This would be a compromise between a full index of addresses per block and re-scanning every trace for addresses if one wanted to build a list of transactions per address (which one would want to do if one wanted to audit a smart contract for example).

What QuickBlocks does: Do not store either the block level nore the receipt level blooms from the raw data. Instead, at each block, build an enhanced bloom filter which (1) includes every address involved in the block including those used as ‘data’ for internal transactions (ERC20 transfers and air drops), fill the bloom filters to a predetermined level (configurable, defaults to 200 bits), and when one bloom fills up, create another one at the same block. Result: significantly less storage devoted to blooms, consistent level of false positives resulting in less overall searching, ability to quickly answer ‘is this address used anywhere in this block’ with perfect fidelity.

Inefficiencies

Sept-Oct 2016 DDos transactions make requesting traces astronomically slow. I wrote about this here and here. Suggestion: easier way to identify (and skip over) dDos transactions.

When you use ‘eth_getTransactionByHash’, the RPC does not return the transaction receipt. In order to get the receipt, you must later call ‘eth_getTransactionReceipt’. You need the receipt to understand if the transaction was ended in failure. Twice as many calls to RPC than needed. Suggestion: staple the receipt to the transaction with an optional parameter to eth_getTransaction.

Transaction Error Codes prior to Byzantium Fork:

After the Byzantium Fork, getting the error status of a transaction is easy. If the ‘status’ field of the receipt is zero, then the transaction ended in error [There may be some edge cases here, we are reviewing this claim].

Prior to Byzantium, one had to search every transaction trace looking for a trace that contains the word ‘error’.

If one is doing historical analysis prior to the Byzantium fork, or trying to gather lists of transactions per account, one has to look at every trace.

Core developers seem more focused on what’s happening at the front of the chain (understandably); rather than getting the data out of the chain. Even though getting the data out is as important.

Suggestion: It would be useful to include a status field in pre-byzantium receipts at the option of the caller of the RPC.

The need for ABI definitions

Get Solidity to make the ABI available, because it makes analysis simpler.

Get people to understand the importance of providing ABIs.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

QuickBlocks is Ethereum-centric; works on Ethereum derived chains. Not Bitcoin.

Every 15 seconds, QuickBlocks polls for data from the node, it then

Optimizes the data for quick, later retrieval

Optionally, stores the data efficiently

Next time user asks for a block, retrieval is faster (it’s a cache).

How QuickBlocks started:

I wanted my own transactions – for my 40 different Ethereum accounts.

Accounting for movement of funds between all accounts.

Initially – was pulling data from Etherscan. But why do this through a website?

Designed to run on a laptop which forces us to stay decentralized

Applications:

When you develop smart contracts, you get event data from web3. But this only give you generated events. In-error transactions are not seen because they do not generate events

Can analyze tokens.

Can do smart contract monitoring / early warning system

Should write monitoring code which watches blockchain – if it notices something weird, your contract can react. If the DAO had had events in it.

Was involved in the DAO. Stunning how little information was available. It took many hours for anyone to notice the hack because no-one was actively watching

I did some analysis of DAO hack. The actual hack is very obvious in the data on the very first block.

Would appreciate intros and connections to other projects.

The code is ready to go. Will be fully open sourced and properly licensed soon.

QuickBlocks won 2nd place at NYC Consensus 2017 hackathon.

Thomas Rush founded the Philadelphia Ethereum group.

We welcome speakers from around the world -- please contact me if interested

A bounty I would pay for––

Kumavis was talking about blockchain data on IPFS or Swarm or another content-addressable distributed storages.

Could build a blockchain that is a chain of IPFS hashes.

A marketplace of block data could grow.

Infura –– could pull the block data from Infura.

I don’t care about the hexadecimal raw blockchain data – I only want the transaction data fully-parsed – stored on IPFS.

From an email follow-up (possible bounty I might pay for):

For a particular range of blocks (preferably in the millions), and using a given list of Ethereum account addresses (one of which will be an ERC20 token, addresses to be specified in the bounty), provide a definitive list of all internal message calls and external transactions along with, at the end of each block, a reconciliation of each address’ ether balances. Additionally, at the end of each day in the block range, provide a list of token holders along with each token holder\'s token balances. The source of the data must be provided. Using 3rd party websites (such as Etherscan) is permitted, but the source of the data must be disclosed. Preference is data provided directly from a local Ethereum node.

The given list of address will be interrelated and taken from a prominent ERC20 token system. One of the addresses will be an regular, external account. Another will be an ERC 20 token smart contract. A third will be a multi-sig wallet. The deliverable will be JSON data showing all internal and external transactions for each address. The delivered data must ‘parse’ the transactions to the smart contracts (that is, the transaction’s input data field must be converted from the hexadecimal to “the language of the smart contract”. The deliverable will be a collection of JSON files formatted using a jsonlinter with specific settings which would allow for diffing results with other methods. Performance metrics will be provided as well. The results must be made open source so as to provide the smart contract auditing community with a ‘gold standard’ of community vetted results to be used for testing/verifying new or existing off-chain auditing tools/software.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '72': { - 'Name': 'Yann Levreau', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Hard to make links between tools.

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

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '73': { - 'Name': 'Gustavo Guimarães', - 'How do you handle smart contract verification and security?': '

Here in Berlin I have worked with solidity,berlin and they are amazing. Do really comprehensive audits.

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Blockchain engineer, working in the space since 2016. Mostly as a freelancer, helping companies solve business problems using blockchains.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Syncing my node to the chain has become really difficult. I used to do this a lot last year, but now I use Infura because the node is so heavy/hard to maintain and it is just easier to do it this way.

Not at all good for fast development cycles.

I have learned to embrace how slow testing can be because everything is async there.

For the raffle system I need to draw a random number, and right now this is kind of impossible in the EVM. The holy grail would be to produce a really random number at compilation time that cannot be tampered with by miners etc.

Right now I am just using an oracle to do this.

', - 'How do you handle testing?': '

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.

', - 'What tools don’t exist at the moment?': '

Would be nice to have a tool that could get bytecode and re-engineer it into solidity code.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Really excited about the research around scaling Ethereum. I am myself working on side project to do state channels.

There was an awesome lecture at EDCON, and was super inspired by David to try it out myself.

Not necessarily in the next 3 months, but there are so many ideas out there that it is bound to be exciting for anyone getting exposed to it.

', - 'Was anything easier than expected?': '

I was pleasantly surprised the first time I connected to a node using Infura, to the point that I decided then and there to not use my own node.

', - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

What I love about Ethereum is that most of the code is out there in th open - so I go and read it.

I often go to the Aragon repos and check out what they are doing and how they do it.

Already mentioned the open zeppelin library.

This is how I learn - just keep up-to-date with the best teams and the latest features the Solidity team is rolling out.

The solidity readthedocs is pretty good.

I have written some blog posts myself about how to do things in the Ethereum ecosystem. I sometimes go back to these and they are often very helpful.

', - 'Are there any other questions we should be asking?': null - }, - '74': { - 'Name': 'Scott Wright', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Just simple stuff - proofs of concept.

Working through course material

Building a token and a very minor escrow app

Timed auction.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

Hasn’t happened across too much yet! Been working in solidity and I find it pretty easy. But how scoping works is confusing.

There was a situation where I was trying to refer back to something and it was doing something weird and I had to dig and find out that behaviour of memory depends on what SORT of memory its being stored to.

So, if you get a lot of JS developers, you need to explain how scoping works in JS and how solidity is different in that sense.

How much of those memory problems are a thing with solidity, or the EVM?

A linter would be very useful!

', - 'How do you handle testing?': '

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.

', - 'What tools don’t exist at the moment?': '

Automated testing - I want a testing suite, a whole tool that is entirely focussed TDD. The work really corresponds to that. Clientless work with many test iterations.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Would have been that initial setup of the development environment, and beginning to build a mental model of what’s going on. Just the setup.

First thing is a soft thing - understanding the difference between a distributed application vs a centralized server application. I’ve taught people some basic blockchain concepts - it doesn’t always make sense to people right away.

The action of calling methods externally on a contract - I kind of understand how that works, and then wait a cycle. There’s a bunch of haziness around how calling methods works though.

And then the exact amount/ability that a method has to change a contract - how much can it do? What are patterns where I could manipulate and kill the contract?

Awesome thing - I love working with apps where there’s no account or login, it just works.

', - 'What are you most excited about in the short term?': '

Vyper!

Have big hopes for truffle - has a lot of the build suite things that I need.

Another thing that’s missing right now is a better IDE, solidity based coding environment right there, so my workflow is that in terminal etc.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '75': { - 'Name': 'Felix Feng', - 'How do you handle smart contract verification and security?': '

Contracted security auditing firm before launching to mainnet and did it internally.

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.

', - 'Other bounties?': '

Debugger

More free automated formal verification

List i.e. Aggregated “Awesome Ethereum” for security (blog posts, tools, etc.)

', - 'Who are you and what are you working on?': '

Founder of Set Protocol, wrote all the smart contract code/unit tests

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Truffle migrate on main net

Weird configuration where generated code doesn’t match source code.

Returns error on Etherscan that the code doesn’t match.

Has to do with Truffle compiler...

Therefore I have to concatenate code myself and deploy using remix.

Revert/invalid opcodes don’t tell you much, logging is pretty much ineffective, code must be recompiled every time.

', - 'How do you handle testing?': '

Started with truffle tests

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%)

', - 'What tools don’t exist at the moment?': '

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Truffle needs to be easier for beginners. Tough for first-time hackathoners...

Going into source code. Things are early and not handed to you on a platter.

', - 'What are you most excited about in the short term?': '

Ethereum proof of stake

0x open source tools.

Metamask replacement by Toshi- needs to be more tools than just metamask.

Zeppelin OS. Upgradeable proxy contracts infrastructure.

Token curated registries, oracle problem, bringing data from off the blockchain to on the blockchain. Token rebalancing from winners to losers could use TCR’s.

', - 'Was anything easier than expected?': '

MVP versions of product are easy. Handling all the vulnerabilities/optimizations/edge cases take 90% of the time.

', - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Consensys Academy

Truffle/Solidity documentation and source code.

Stack overflow

', - 'Are there any other questions we should be asking?': null - }, - '76': { - 'Name': 'Simon Jentzsch', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

CTO of SlockIt.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

IDE integration

There are tools and plugins for different IDES. Being able to use Solidity just like any other language would be really nice

Do just the basic stuff right.

Checkers/linters exist but they’re all over the place. Integrated into IDE, not via CLI, would be helpful.

Package manager for existing libraries needed that could manage packages and bundle them in a secure way

Manage standards better

Not just syntax highlighting, but code-assist/completion and deep syntactical and structural understanding.

Web3 Libraries

Latest updates broke all our tests, so reverted to fixed versions

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

Scalability is long-hoped for and looked forward to ;)

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

', - 'Other domain specific questions?': '

IOT security challenges?

Use blockchain to enhance security by using smart contracts for access-control

Devices are dumb, smart contracts grant access

Downside if how to get a stable connection which is secure and able to run on low hardware specs

Clients that are able to run on small IOT devices is a big challenge.

We’re developing light client IOT device, Incubed - not just light client but IoT client for microprocessors etc. Can do verification without even syncing with headers.

Devices that need to sync just a few times a day, in unstable WIFI env.

Network of full clients running on servers. Incube randomly choose nodes out of the networks. Send JSON RPC request, answered with signed block hash/header.

If you send wrong block hash, then they lose their deposit.

How do you store a private key on IOT device?

IOT device pvt keys generated from unique aspects of that specific hardware so that each device can easily generate its own key without transporting it anywhere

Paying for gas from each device is a big challenge.

Trying to integrate with uPort and others for app key management

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Having people around, trying new things, debugging existing ones. Most important is talking to and working with people who know more than you do - there is no substitute for that it seems.

', - 'Are there any other questions we should be asking?': null - }, - '77': { - 'Name': 'Fernando G', - 'How do you handle smart contract verification and security?': '

I always try to keep myself on top of existing known vulnerabilities and the new ones. I have a repository with proof of concepts of most of them, and I run unit tests demonstrating the bug and the fix, in that way I have a practical view of the known security bugs. Then I try to audit my contracts using the knowledge I acquired and the tools available, mythril formal verification, mythril analysis, manticore, porosity

', - 'Other bounties?': '

I think anything related to ease the whole lifecycle of developing Smart Contracts is a good candidate. A good IDE (or plugins for existing matures IDEs), with integrations to common services and tools like embedded 1 click debugger, 1 click deployment with builtin interaction with on chain contracts would be a game changer.

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)

', - 'Who are you and what are you working on?': '

I am a developer, working in London for the last 4 years, I love coding in general, but also security. I am joining ConsenSys next week and I am working in several side-personal projects, including the solidity-graph-debugger

', - 'What are the tools/libraries/frameworks you use?': '

Well, it depends, when I build tools related to Ethereum, I tend to use the Java ecosystem (Java8, Maven/Gradle, Spring if it is a web application, etc).

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.

', - 'What are your biggest frustrations?': '

Maybe it is my fault, but I would like to see more tooling around other languages (especially Java, that is the one I am more comfortable with), but I know some people who are working on it at the moment, like Conor and his team from blk.io, they are doing a great Job.

I am not a huge fan of JavaScript, and most of the modules are more maintained in JS (which does not mean better code!), so sometimes I have to adapt and use them. Anyway that\'s not a huge deal, I am not that extreme and I am fine with using any tool that can help me to achieve whatever I have to do

', - 'How do you handle testing?': '

For unit testing I use truffle, I write JavaScript tests, it works great. I use Mythril if I am auditing my contracts, I identify some really important invariant and I write a little script to formally verify it, and Mythril is great for that. Manticore can also do that, but didn\'t have the time to test their scripting APIs (something I have pending)

', - 'What tools don’t exist at the moment?': '

Good question, there is a lot of ecosystem that has to be created. The most obvious thing, would be a graphical debugger that is what I am building, but also dependency management tools, good IDEs (intellij solidity plugin is cool, but like everything right now, it\'s a bit green), better documentation tools, clients for pretty much everything, an easier way to interact with contracts for the average non technical user...

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Scalability improvements. I want sharding and PoS (if you can call that short term, maybe I am an optimistic person)

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Hmm not sure if you spoke to Bernhard Mueller, seems a pretty interesting person to talk to.

Security people in general. Also Conor Svensson, interesting to see what he is trying to do regarding with tooling in general and adoption of different ecosystems

', - 'What are the best educational resources?': '

I would say no books, because they get outdated 1 week after the release, read the official documentation and start straight away to test things by themselves. Fight and fight more, then read again the documentation to grasp things that were missed the first time, then keep practising and do that in a loop until things start to make sense. Then I would try something like Cryptozombies, to learn a practical point of view, and solve Capture The Flag challendes, like OpenZeppelin Ethernaut or capturetheether. With those you will learn basic (and complex) security issues which are absolutely essential to be able to deploy anything in the mainnet

', - 'Are there any other questions we should be asking?': null - }, - '78': { - 'Name': 'Dandelion', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

SourcCred - bounties and reputation for open source work.

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

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Highly adversarial environment makes it hard to feel safe. Wants to develop SourceCred outside of blockchain as much as possible before moving to Ethereum as late as possible. A misstep in the Ethereum ecosystem could have disastrous effects for project.

It would be really great to see better documentation and more static typing in the ecosystem.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

At core abstractions layer. If SourceCred depends on Foo library. Every time I mint SouceCred tokens, I want to give SourceGrain token to not only contributors to SourceCred but also the Foo library. But in Blockchain it is very difficult to Iterate over all of the objects.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

CryptoZombies really improved my intuition.

', - 'Are there any other questions we should be asking?': null - }, - '79': { - 'Name': 'David Wolever', - 'How do you handle smart contract verification and security?': '

Front end: nothing really

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)

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Been working with Spankchain team. Combination of state channels and smart contracts.

Also worked on smart contract for ICO auction.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Gas limit: No problems with this really.

Metamask was giving absurd gas prices because another service was getting it wrong.

State Channels: Have had a pretty good experience there. Biggest time sync is blockchain to database synchronization. David wrote something for using state channels with SQL. Insert transactions from a block, insert signed messages, and get balance for account.

Biggest frustration is getting block messages into the database.

Wrote a tool called Chainsaw that does this. No mechanism for a reorg.

', - 'How do you handle testing?': '

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

', - 'What tools don’t exist at the moment?': '

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

No real breakdown of how everything works together

Web3 talks to a geth node which has the blockchain state. What does the contract do? How do you deploy it?

General how stuff works.

', - 'What are you most excited about in the short term?': '

Ours. Spankchain.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Why are people building dapps instead of just building them with a normal database or something?

What is your motivation for choosing a blockchain based project, instead of just a Postgres database?

' - }, - '80': { - 'Name': 'James Young', - 'How do you handle smart contract verification and security?': '

We had multiple audits at multiple periods of time. Had to just to make sure that to have a semblance of security, had a bug bounty. Left a subtle bug to make sure audit was legit.

', - 'Other bounties?': '

Getting mainstream users onboarded. Informed by practical problems, just getting ETH. Cold start problems. Ways of getting around this, using Gas Relay. What would be interesting iswhere dApps, applications have pre-funded. EIP-186 where you can have the dApp pay for gas.

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.

', - 'Who are you and what are you working on?': '

Work primarily with Spankchain, doing state channel research/implementation. Also worked on Adtoken, first production release of TCR.

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.

', - 'What are the tools/libraries/frameworks you use?': '

We use Truffle, and Ganache on the web3 blockchain side of things. On traditional web2, use node, Kubernetes, Docker (traditional scaling pipeline).

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.

', - 'What are your biggest frustrations?': '

When I’m doing unit tests in Truffle, not knowing where the revert came from. Have been talking to the Mattis network, they focus on plasma. If the contract throws or reverts, it will tell you the line number.

Writing the smart contracts is 20% of it, testing is more like 80%. Being able to have better clarity and visibility on the tests would be great.

My biggest fear or anxiety would be knowing if there are any bugs are in the smart contracts. Trail Of Bits has been working on a Fuzzer, having tools like that is would easy a lot of frustration.

', - 'How do you handle testing?': '

I test and retest. Wrote the auction contract in Spankchain, the only payment channel auction ever. The contract itself was 150-170 lines (including comments). Had to document well and had 3 audits, but tests were over 2200 lines long.

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.

', - 'What tools don’t exist at the moment?': '

I wish and a hope there is bachelor’s in blockchain. In blockchain, you have to know legal, economics, game theory, some coding, etc. Here‘s the best curriculum so you can understand for yourself, is this mechanism design good. Some cryptography. Need to be able to give people the fundamentals. Need a broader view, not just technical.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Knowing what Gitter channels, Slack channels, places to go. And Online identities. Knowing who to trust. Being in the Consensys Slack channel, that’s so great as there’s lots of sharing of knowledge there.

', - 'What are you most excited about in the short term?': '

Actually having micropayments be a thing and scalability be a thing. Everyone talks about Floppening, where Ethereum overcomes Bitcoin. But that floppening fo me is if that txs offchain are more than the onchain transactions. That is what is really exciting. Now we won’t have a limit, we busted through that limit. Hope to happen this year.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

I would actually talk to operators that have successful startups. There is interest there. Learning how to run and operate a businesses. This is what is also really needed in the space. There are analogies to the beginnings of the Internet. How DNS became DNS. This would inform, this history you don’t really hear about. How did social games become mainstream? Was FB leveraging off of Myspace? What were those key learnings there? Ethereum as a technology, getting a healthy mix of people that have been there and drawing analogies and lessons at a higher level can be extremely useful

List of successful operators that have done 2-3 exits in companies before. The space can move very fast. Needs to be rounded out by successful operators and implementers. Instead of writing papers, let’s implement it. You get the real life pain points.

State channels don’t matter if you are still like, “How do you begin?” Can be more open about failure, be more honest about this. Harder to learn from success than to learn from failure, good to have a safe environment to learn from failure.

', - 'What are the best educational resources?': '

Depending on the background, a lot of it is hard because the docs get stale so quickly. Hard pointing them to the right version of things. When people ask, they just train themselves. They build their own blockchain developers, he teaches Solidity classes.

Don’t point people to any one example, his tactic is to give them a couple of books like Radical Markets and 5,000 Years of Debt. If they are willing to read that he is willing to spend his time with them.

', - 'Are there any other questions we should be asking?': '

Human behavioral things, what holds your feet to the fire? What is that motivates you? What keeps you on track? What are you doing now and how do you hold onto this track? It’s sometimes better to have these constraints, so when you don’t have these things what makes you sure that you’re on the right track?

See a lot of projects waiting to see, but have to implement. Have to have the real-world conversation instead of academics. Need to get this feedback and keep going. People wanted to play Farmville just because it was up, this is what informs him now. For Spankchain just gotta launch, then you know what you really need to solve.

So ask why are you doing what you are doing!

' - }, - '81': { - 'Name': 'Doug Hoyte', - 'How do you handle smart contract verification and security?': '

Trying to keep everything as simple as possible, reduce attack surface, minimise dependencies, the usual. We have a pretty comprehensive test-suite, and perform white-box invariant tests after every interaction.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Doug Hoyte, working on sportcrypt.com, a sports betting exchange. I\'ve also consulted on a few other ethereum projects.

', - 'What are the tools/libraries/frameworks you use?': '

web3.js, ethereumjs-util, solc, testrpc, parity --dev, metamask

Overall it\'s pretty easy to get started, which is nice. For dislikes see next question.

', - 'What are your biggest frustrations?': '

Docs are usually out-of-date, plain wrong, or both.

All libraries, docs, interfaces, etc have ossified around the web3 API, which is basically a wrapper around a trusted RPC interface to a node, so it may as well be a client to a centralised system

Very difficult to provide good UX with ethereum \'nonce\' system: having multiple transactions in flight at once doesn\'t work the way people expect them to (\'nonce\' is a misnomer anyway -- only way to cancel a transaction or resend with a higher gas price is to reuse a nonce, something you should never do with cryptographic nonces)

Everything is built with polling in mind, even when a push notification system would be superior. Need to poll infura constantly since you can\'t subscribe to events. Inefficient (wasted bandwidth/CPU) and bad UI (users aren\'t notified as soon as possible when something happens)

Off-chain signature APIs are inconsistent across implementations, in multiple different ways

When signing data in metamask, users see a bunch of gibberish unicode characters. Proposed solution was to make a \'good enough\' schema instead of, for example, re-using the solidity ABI

Things not directly related to consensus don\'t seem to be well designed: The \'sandwich\' model of complexity (where you assume someone else will come and do the hard-work of integration so you don\'t have to) hasn\'t worked great so far

Metamask silently pushes down updates to users without their consent, occasionally breaking things (and of course they could steal all your eth if they ever wanted to). They also have a built-in censorship infrastructure now (supposedly only to use against phishing sites, but potential is there for anything)

Testnets like rinkeby make you sign up with your facebook account or something to get coins

Solidity compiler misses some trivial optimisations, has odd limitations like max number of local variables, and handles memory vs. storage qualification in subtle ways

', - 'How do you handle testing?': '

Custom test harness, could never figure out how to get truffle to do what I needed

', - 'What tools don’t exist at the moment?': '

Hmmm, a good light client implementation so everyone doesn\'t centralise around infura/etherscan, although that ship has probably already sailed

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Working around web3/metamask bugs

', - 'What are you most excited about in the short term?': '

Building out our product, watching adoption grow. In terms of ethereum itself I think there is a lot of legacy stuff and bureaucracy that will impede improvement, so I\'m not holding out much hope there. Time will tell of course.

', - 'Was anything easier than expected?': '

Solidity is supposed to be completely awful so it came as a surprise to me that it was actually fairly reasonable

', - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Not sure. Solidity docs are OK if you are technical

', - 'Are there any other questions we should be asking?': null - }, - '82': { - 'Name': 'Ricardo Guillerme Schmidt', - 'How do you handle smart contract verification and security?': '

No major process. “This function should do one thing. Only that. If it can be used to do anything else, that’s a problem.”

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.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': '

Microsoft VS code, Git, Remix for manual tests, Truffle, Parity.chain for testing, Mist & Parity on Ropsten for development

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.

', - 'What are your biggest frustrations?': '

Being unable to returns strings nicely. Regularly blocks me.

My project GitPivot connects git to the blockchain and generates tokens for commits. Needs to store git usernames, but can’t. So instead has to store a hash.

But that means he has to ask the user for their username each time so he can check the hash, which is a bad user experience.

Scaling!! Scaling is actually the biggest problem. If Ethereum nodes can’t handle the state it will all become useless.

Are you running into problems with any of the following:

Gas limit:

Yes. Not for deploying, but when users are adding to big arrays it can get complicated.

Off-chain computation

Yes, same problem with arrays, with on-chain computation. Sokrates? Not sure if zkSnarks will be able to solve this.

State Channels

Haven’t used them before.

', - 'How do you handle testing?': '

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.

', - 'What tools don’t exist at the moment?': '

Would be very good if VScode had the same thing that remix had - i.e. an actually Integrated IDE.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Not sure, not actually difficult. If you understand decentralization, it’s easy. If you don’t, then there’s no reason to try it.

Immutability makes you more cautious when going to production.

What would be the hardest part of teaching somebody to build a dapp?

Depends on the user. If the user is good in JS, it would be understand the fundamentals of the smart contracts.

Explaining fees & immutability.

Biggest problem is they don’t see the whole picture, just get 1 part of blockchain technology.

', - 'What are you most excited about in the short term?': '

Excited about Golem. I really want to use it because I have a powerful GPU at home that is not mining. I want to do something useful, not just use my GPU for mining.

Love Ethereum for proof of stake, that was my main interest in it at the beginning.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Jordi Baylina, James from Status, Luis Cuende from Aragon.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '83': { - 'Name': 'Richard Ramos', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Smart contract developer at Status, also working a lot on Embark.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Working with MetaMask and your local node/test environment is often unstable and connecting it locally can lead to strange issues that are very difficult to debug, as your contracts work fine in tests, but then fail arbitrarily in the browser.

Not having breakpoints in Solidity is hard. It would be awesome to able to see more clearly the flow of the code and follow things through the stack with some suggestions/explanations.

Last week, when deploying some contracts through Embark, it just read my contracts as interfaces and so didn’t compile them.

Not an Embark error - it comes from solc, because there was an error about the “stack being too deep” which happens when you have more than 16 local variables (which is not well documented anywhere that I know about).

The error behaviour in general is weird and difficult to follow. Better documentation around this area in particular is very much needed.

Seriously though, most of my frustrations are related to debugging.

', - 'How do you handle testing?': '

Mostly through unit testing in Embark. I created a new feature for it (not yet released yet) that lets you create a small scaffold for the unit tests you need for any given contract.

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.

', - 'What tools don’t exist at the moment?': '

If I want to build things that are secure AND cheap to use, this is really difficult because we don’t have an existing scaling solution.

', - 'Other domain specific questions?': '

Let’s talk about Embark further. What do you see as the most important tools you’re building?

Easy storage/uploading to Swarm and IPFS. Swarm in particular as IPFS support has been there for a long time.

Swarm has unique support for DApps and we are building some examples that use state channels and other interesting scaling solutions being developed.

These sort of example projects (well beyond SimpleStorage) allow us to put ourselves in our users’ shoes and understand what can really be done and where the pain points most often are.

Embark is planning to integrate the Remix debugger as well.

Tracking how the value associated with variable changes in the course of running specific transactions etc. is a very important feature for us.

Embark also has Whisper support, which can still be improved a lot.

Right now, we try to simplify the experience of using Whisper, but it therefore lacks some flexibility.

I am not able to specify a private key that links to a public symmetric key. E.g. when working on the gas relay node (a node-js service that subscribes to a whisper symmetric key) and we have to do it manually using the web3js library because the whisper functionality provided by Embark specifies the keys automatically and it is not currently possible to change them.

What is the gas relay node you mentioned?

It lets you perform transactions without actually holding Ether. It works by sending a signed message (through Whisper, or p2p, whatever). The signed msg is parsed by nodejs service and it will use the ETH that service has to create that transaction for you and will deduct the amount of required tokens from the account that sent the signed messaged.

It is ready to be demoed internally, but we need some additional input.

This solution needs to be included in the app, the desktop app, and perhaps even in the mailserver nodes, so requires a lot of feedback from our different teams.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Status!!!

Plasma cash is really interesting and I follow it closely. Omise Go is an impressive team.

', - 'Was anything easier than expected?': '

Learning solidity and writing your fist smart contract is actually very easy.

It’s the edge cases and optimisations that are hard ;)

There are some good best practices that you can follow pretty easily and all the big hacks have been well documented, so researching why they happened is easy and will teach you a lot about writing better and more secure code.

', - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Subreddit for ethdev and stack overflow, as always.

Cryptozombies is cool.

I learnt SO MUCh about smart contracts from ethernauts.

I like reading HackerNoon on Medium - there’s some interesting stuff there.

', - 'Are there any other questions we should be asking?': null - }, - '84': { - 'Name': 'Bob Summerwill', - 'How do you handle smart contract verification and security?': '

As good as that gets right now, there are various guides to best practices. Consensys has a really good one. Leaning on Zeppelin, Consensys Diligence, zklabs. Fairly small amount of people that have expertise, real dearth of people.

Consensys Diligence was super swamped for requests right at the start. Pay someone to stop working on their project.

', - 'Other bounties?': '

Work for GUI’s, development tools for GUI’s. Can we get to a level where Visual Studio/Visual Studio Code/ Atom? Interactive debuggers is absolutely #1. Single stepping through it.

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.

', - 'Who are you and what are you working on?': '

Been involved with the Ethereum community since 2015. Worked for Foundation, and then for Consensys, then at Sweetbridge. Bootstrapping current efforts.

', - 'What are the tools/libraries/frameworks you use?': '

Most of his work has been on the platform work itself or on the community side. Truffle and Remix are the leading things. Embark and Populus, a little bit. Metamask, very important. Mist not so much, it really needs a bullet in the head. Was a good idea 4 years ago. No one wants a desktop browser.

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.

', - 'What are your biggest frustrations?': '

Where we are at now is a transition between amateur and pro. Needed for a long time but starting to see now. We’ve got so far in research and development stuff and volunteer time. But we really need to get professionals in. Software engineering side, community, and business side. And a million other things. UX is a chasm between where we need for mainstream clients. Unusably terrible for end users!

Same on the development side. We’re not even in 1993 in the web, we’re in 1986 and a core dump could happen at any time. Swinging samurai swords around, do not give these swords to normal people!

Even on the developer side, layers and layers of shit. Far get to where we need normal development. As we’ve seen through hacks and flaws. Can’t write backbone of the banking industry.

Formal verification is not done for normal software. To get to mainstream, we need to be composing pieces more. If you’re an iPhone developer, think of all of the tooling you have available. Everyone is building their own bricks still in the space.

But this has happened before, we want this to be as simple as writing a web app. IDE single stepping. Automated builds and quality checks. We need to be it as simple.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

Interactive debugging. Truffle and Remix have started to have little bits for that. What you really need is a nice GUI debugger. VSCode or Sublime, you need step-in debugging. Visual Studio would be ideal, step in and step out.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Where are the tools? There’s nothing, going back 30 years ago.

', - 'What are you most excited about in the short term?': '

I am excited about preaching about the end of tribalism which seems to be working a bit. Don’t have to argue about blokchchain being a thing any more. But how can we ship? But need to get a version where people can build real things.

Supply and demand are starting to marry up. Central banks have done their proof of concepts, great for stock markets. Getting to answers for scalability, privacy, and useability. We’re at the state where we interview people on what do we need? For the last few years, if you solved scaling then maybe we’d be interested. We need money! Now we have it. We’ve got people pairing this together to get stuff done.

On the enterprise side, loads of blockchain jobs. If you like the area you can get in and have that stability. Becoming another part of technology. Success is when blockchain becomes boring. Then we’ve won.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Some universities starting to teach, Consensys Academy, have to cross-train.

Get involved in a local meet-up, it’s all about the people. Find people near you that are already involved. Nothing else is mature enough. Hardly any books, just got Mastering Ethereum coming out at some point. This will be legitimately useful at some point.

IC3 are doing a bunch of stuff. An increasing number of people in the community are starting to do more technical blogs. Demonstrating legitimacy by demonstrating value.

Ric Burton has been fantastic recently, great blog posts.

', - 'Are there any other questions we should be asking?': null - }, - '85': { - 'Name': 'Yaniv Tal and Brandon Ramirez', - 'How do you handle smart contract verification and security?': '

Instead of statically linking contracts, you find the library that already has what you want and you call functions on this blockchain. This is pragmatic from the gas standpoint but raises security questions on the dependency.

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.

', - 'Other bounties?': '

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.

', - 'Who are you and what are you working on?': '

Yaniv and Brandon from The Graph, query protocol for getting data off blockchains and storage networks

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Artificial limitations in Solidity, number of parameters in a function call, or variable length for things that you are returning. In 2018, really? I think this is the Solidity Compiler, don’t think this is the limitation in the EVM. The stack limit is the other thing, you can’t write good code that is abstracted well, you have to write stuff around the compiler.

Getting data out of blockchain is hard. Our project is trying to solve this for the community.

For Ethereum, lots of parts of the engine are getting swapped out. Move to Vyper, will this be the preferred language? Area has a lot of churn. With move to eWasm, will there be a move away from EVM? Need clear guidance on how things are going to be upgraded. For eWasm, have a development environment for this so people can experiment on this. Giving people a way to experiment and to run on things.

Solidity events are just sugar on top of low-level logging capabilities that EVM provides. Solidity events are just a convention that is built on top, but unclear how this breaks abstractions on top of the EVM that isn’t part of the EVM itself. But this might not be able to be represented across different languages as they move to them. How much will break when people move off Solidity?

', - 'How do you handle testing?': '

Write a lot of tests, try to make them as comprehensive as we can.

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.

', - 'What tools don’t exist at the moment?': '

Pretty common for people to develop contracts locally but don’t really know what gas costs are, and then they deploy to testnet and Mainnet and are surprised. Compile time tool for estimating gas. Embark 3.1 has a Profiler :)

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.

', - 'Other domain specific questions?': '

How have you found working on Aragon, esp. APM?

Overall, I like the direction of APM, with a registry that also spins up the IPFS node with artifacts auto-deployed on it.

The devil is in the details and it can be quite complex, but it’s a promising direction.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Plasma stuff. Obviously early days, but we want to see Plasma stuff ship.

State channel stuff is still interesting. Obviously sharding and eWasm. All scaling stuff.

We like Vyper, which is a more functional, formally proven language.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

CryptoZombies, used to send people to Zasterin which had some good courses. But not sure if this was updated in a while

Looked at a bunch of Truffle tutorials.

Big picture stuff, podcasts like Unenumerated. Preethi has some really nice high-level Medium posts.

', - 'Are there any other questions we should be asking?': null - }, - '86': { - 'Name': 'Sina Habibian', - 'How do you handle smart contract verification and security?': '

A bunch of upfront discussions and security analysis.

Then writing tests.

Security audit, bug bounties

Then, we will run a beta on the mainnet

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

I started in January or February of this year, and used a tutorial on Medium for creating a voting system.

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

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Super slow cycle due to testing.

Are you running into problems with any of the following:

Gas limit: Yes, for local testing enforcing gas limit.

Off-chain computation: Yeah.

', - 'How do you handle testing?': '

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

', - 'What tools don’t exist at the moment?': '

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Wrapping my head around potential attacks and edge cases in smart contracts.

What would be the hardest part of teaching a software engineer to build a dapp?

Incentives and economics angle is the hardest part to teach people, but likely the most important.

', - 'What are you most excited about in the short term?': '

TrueBit because it gives you the ability to run any piece of code and get the result back no matter how long it takes

ArtDAO

Smart contracts are self owning but don’t have any intelligence.

AI’s are evolving and learning, but they don’t have any resources.

AI creates 5 pieces of art and puts them up for auction. Sees the prices.

Keeps making better and better art, and the goal is to maximize how much money it has

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

Dan Finlay

' - }, - '87': { - 'Name': 'Truffle Team', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Set of tools: linters & coverage tools

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.

', - 'Who are you and what are you working on?': null, - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

It’s downstream on Etheruem and Web 3js; upstream from developers

Needs to act reactively with what comes down the pipe from web3

Needs to act proactively to help developers

Solidity develops faster than we can go through their process & do their QA.

Need to bump the version –– but solidity sometimes introduces breaking changes –– 4.11, 4.12 – e.g. visibility modifiers; but hasn’t happened in a while.

A range of projects: sophisticated projects (Aragon) but also people who don’t know how to use npm.

We’ve been conservative about how we upgrade

We’re making solidity stricter and stricter; but we don’t know what kind of crazy stuff people have written.

Solution: try to make the tool configurable; based on plugins; users can make it into their own thing.

Making the compiler configurable.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Integration between truffle & ganache?

We’d like their tools to provide a cohesive set of tools.

Takes time to build and just figure out what the requirements are.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Currently we use Gitter. Every Truffle member spends time in there.

But we don’t think Gitter is the right tool for Truffle’s entire community support

Need to see what messages were missed.

People find bugs or issues that just don’t get serviced, we fall through the cracks

Need a better way to announce to our community

We have a mailing list

We can message on Gitter – but people miss the messages

There’s some first-class moderators on there.

Detailed answers are so helpful and seem to come through often in places other than our docs, which is hard to manage.

Stackoverflow is a great resource – look at questions on stackexchange to find what things are creating the most problems for users – where the anger is.

', - 'Are there any other questions we should be asking?': null - }, - '88': { - 'Name': 'Preethi Kasireddy', - 'How do you handle smart contract verification and security?': '

In the past, OpenZeppelin. Don’t think we’ll use them again because they are a bit pricey.

', - 'Other bounties?': '

Testing and debugging!

Key management stuff.

', - 'Who are you and what are you working on?': '

I’m the founder and CEO of Trustory, an app that’s built on the blockchain. App for users to create stories, and stories get validated using a cryptoeconomic game. Stories are claims that people are making!

Before that, I was doing independent development and was an engineer at Coinbase for a while.

', - 'What are the tools/libraries/frameworks you use?': '

With Ethereum, for Trustory, we will write smart contracts in Solidity but maybe also make extensive use of Go.

Tendermint Consensus engine to build our sidechain with.

Other Cryptolibs TBD.

', - 'What are your biggest frustrations?': '

Not enough standard libs. Creating a dApp, the stack is not well-defined. The ecosystem is very early with a lot of breaking changes and versioning problems.

Scalability, privacy. People are still figuring it out. Very few people are working on sidechains.

Not great documentation.

', - 'How do you handle testing?': '

For JS, Mocha/Chai. In the past, used py-ethereum. For now, TBD.

', - 'What tools don’t exist at the moment?': '

Debugging. We don’t use Truffle, and if you’re not using Truffle, it’s kind of impossible to debug your contracts. Truffle is not the future, it feels very restrictive. If you’re not using Truffle it’s difficult.

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Everything. Nothing follows a standard.

Biggest thing was debugging and testing. You don’t have a proper debugger, life is hard. Deployed the contract every time, had to fix it every time, very manual.

', - 'What are you most excited about in the short term?': '

For my app to launch!

Excited for Casper, for Proof-of-Stake

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Head of Tendermint, Zaki .

Antonio Juliano CEO of dydx (have previously spoken to Brendan Chou).

Nadav of Dharma (interview #19)

', - 'What are the best educational resources?': '

Read the Ethereum source code, read the Solidity documentation.

I learned by reading source code. Read Ethereum for depth, and then read Solidity docs. Looked at as many contracts as Solidity contracts as possible.

Top projects: 0x contracts, Gnosis contracts, Augur contracts. Looked through top projects.

Some people look at Consensys tutorials, but I personally don’t like them because they lock you into their ecosystem.

', - 'Are there any other questions we should be asking?': null - }, - '89': { - 'Name': 'Alexey Akhunov', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Unification of testnets[a].

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.

', - 'Who are you and what are you working on?': '

Been in Ethereum since the beginning. Was following the PoC. Mined few blocks on his home computer.

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.

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Yesterday – spent 3 hours!!! – fixing compiler errors. The codebase is large.

Added an extra flag to switch db to another from LevelDB. Compiling errors in fast-sync and light-client.

Codebase has a lot of baggage: Geth has Whisper, Swarm, and light-client.

Do geth developers want to separate these out?

Potential concurrencies & SSD improvements.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Optimizing Geth:

It all started with a rough kinda experiment – in November network became congested –

Started doing profiling in Go. Learned to do it then.

Saw that geth was mostly talking with LevelDB database.

The process:

1) look at the profile

2) ask questions – why is it slow?

3) then look at code, edit, experiment to improve.

The system is complex – hundreds of goroutines running at the same time.

Trying to optimize the state management. State is constantly growing. Things will have to be written on disk; fetching it again will be slow. Can have cache, but what if it’s outside of the cache.

Problem 1) speed of processing.

Problem 2) if you’re running a full node –

Fast-sync: download all the headers + download enough state objects from other peers to only verify randomly selected blocks.

Then, after this, you become a full sync node.

Whole state from beginning is ~ 600GB.

It needs to be compressed.

How do you test your optimizations:

Peter from Geth told him: you can export the blocks, run through your node without being connected to network, and process.

Jameson Lopp:

His criteria for a blockchain: how quickly it syncs.

Idea for bounties:

Shared resource: have block data sliced up into pieces (e.g. first 100k blocks, second 100k blocks etc.), give it a Github branch, spin up the image, it does a git pull, launches an instance of the client without p2p mode, imports this part of the blockchain, does comparison across different parts (e.g. when there was a spam attack in ~2.4m block)

My goal: to go through spam blocks really quickly. Every sync should be very fast.

People complaining (e.g. exchanges) that they can’t keep up with the blockchain – e.g. Etherscan – falling behind. The clients are becoming inefficient. Instability problems. “When quantitative changes become qualitative” – breaking points are hit.

Go-ethereum developers are also working on this – I do the same – but I like not having the responsibility and just hacking around.

Collaborations between different clients: Parity & Geth

Parity had a great breakthrough – how to tune parameters of database – can sync on HDD. I’m hoping that collaborations will grow. State management across clients is important.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Nick Johnson

Peter from Geth.

Quickblocks founder – Jay Rush – quick access to blockchain data. Working on the problem of quick state download.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '90': { - 'Name': 'Simon de la Rouviere', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

Autonomous artist blueprint has existed for more than a year. Someone just needs to copy-paste and build it: https://medium.com/@simondlr/lets-summon-an-autonomous-artist-a-bot-that-creates-owns-and-sells-its-own-art-ada1afad086a

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.

', - 'Who are you and what are you working on?': '

I have been in blockchain since 2013 working in BTC. I have always looked at this stuff as a tool to enable creators, so I built an app that let people sell digital goods for BTC.

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.

', - 'What are the tools/libraries/frameworks you use?': '

I am the smart contract lead at Ujo, so spend most of my time writing Solidity and tests.

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.

', - 'What are your biggest frustrations?': '

For me, it’s always been harder to evaluate this, because I come from building on BTC, which is orders better than the dev experience there.

It’s always been “good enough” for me, even though it is improving rapidly all the time.

Issues with Infura detailed above cost me quite a bit in failed deployments, and the only way I figured it out was by having direct access to the Infura team, which others obviously won’t and that is an issue.

How deployments work with different gasPrices - it’s not clear if you should worry about things like time outs during the process. What if you set a low price, end up waiting hours, and your internet suddenly drops? What if there is a time out on the request to an API somewhere that fails?

I always default to a higher gasPrice when deploying to make sure it actually passes and is including.

Better documentation around best practices and common pitfalls here is definitely needed.

Ganache has visual interface to their test explorer. Sometimes you want something with a more visible understanding of what transpired with certain transactions. Like etherscan displaying internal transactions and well-known contract events, but with visuals.

Visual analysis/element would really help developers understand what is happening in the network.

When you have multiple contracts for a DApp, you need an up-to-date document/visual interface that shows you latest deployed contract and its methods/interfaces.Auto-generating visual tools for SC that are meant for developer aid.

At Ujo, we have 4 contracts, a registry, a payment handler, badges (collectibles), oracle. Gets put into JSOn file in /build, but this is not visible or particularly useful for anyone but me.

Take some info out into separate document so the rest of the team can easily see where they are deployed and what they do at a higher level.

', - 'How do you handle testing?': '

Mythril is very useful and we use it.

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.

', - 'What tools don’t exist at the moment?': '

One thing that comes to mind is a mature, incentivized storage platform does not really exist, still. Swarm has never really answered my immediate needs, and I worry sometimes that it is a bit too similar to something like S3.

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.

', - 'Other domain specific questions?': '

What are the biggest challenges for Ethereum right now?

It’s still uncertain to me how the development experience will change when scalability improvements start to get deployed.

Whether it is sharding, plasma, side channels etc, what changes from a development perspective?

How do we choose which shard to inject our contracts into? How does the network load balance this?

What does a dev need to change for Plasma, and what does it mean for UX? Does it need a separate MetaMask, or do we need to build our own in-browser wallets again?

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Curation markets!

More collectible stuff. The art scene is finally catching on, which is great. The cypherfunks, which were four years too early, are being discovered again through no work of my own, which is awesome.

I just want more people to be able to do what they want to do, more often.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Google, gitter, ETH stack exchange.

Some Consensus resources that we all use.

Most of Consensys’ internal stuff is moving toward being external-facing and most of his stuff should be open in the future.

', - 'Are there any other questions we should be asking?': '

Curious about how we plan on dispersing the money? How do we decide on spinning up new teams to work on stuff or find existing teams working on it and enabling them.

Wouldn\'t make sense to fund multiple implementations of something? Take the block explorer: what about etherscan, alethio etc?

' - }, - '91': { - 'Name': 'Alvaro', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

VirtuePoker – offchain game, smart contracts to represent state of a poker game – offchain consensus of consensus, and submit to onchain.

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

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Whisper

Building a p2p game. We tried using Whisper for real-time communication – does not have receipts; we have discarded it right now.

Read a Stackoverflow about Status’ problems building on top of Whisper.

The P2P is tough – need to be direct peers –– need to run neighbor nodes yourself.

Connecting the mesh is tough.

SO post said that Whisper doesn’t acknowledge receipt of messages.

Running whisper on a geth node is optional.

PROBLEM: whisper has low adoption.

As a result, the game cannot be decentralized. All messages that are passed to each other between clients, are going through a centralized center.

People use WebRTC with direct connections. But won’t work for them because they don’t want to reveal people’s IP addresses.

There’s also a protocol called Telehash.

DHT.

Web3

Switching to new release soon – interface change is coming.

Callbacks are annoying; should use promises.

We promisify the functions themselves.

We’ve only used web3.

A web3 alternative, ether.js (from L4)

Solidity

Why doesn’t it have common data structures? e.g. a simple array; if you delete one item, you get a hole in the array.

Need a way to store data that is indexed and where it can be safely deleted. Manually doing this stuff is bad..

There are many implementations of this; but having a standard implementation would be really helpful.

A lot of these things should be built into the language.

SafeMath. I don’t use a lot of libraries otherwise.

EthPM? -> It worked, kinda?

Creating more low level libraries[a]?

I like Remix. It has improved a lot.

I had no problem with the UI.

Like testing in Remix – though the debugger could be improved.

Truffle is good, as well.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '92': { - 'Name': 'Javier Franco', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

How to simplify the way to calculate the gasPrice.

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.

', - 'Who are you and what are you working on?': '

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Gas costs:

Ethereum price increased, gas priced also increased, then CryptoKitties launched –– gas cost of $1. We think the only solution is Plasma.

In the beginning, it’ll be only a chain for payout. Won’t have the EVM. The first Plasma implementation won’t be a EVM – will be only for sending payments.

We’ll be moving from this to a payment-only architecture.

Documentation is very weak – Plasma especially.

New joiners, suffer when learning. Compared with, say, Javascript.

Especially since we’re all in a phase where new developers are entering.

Ethereum Foundation examples has not changed in a long time.

There’s no rollback when you deploy a contract.

Deployment costs of a contract is expensive – the Dutch Auction for their ICO costs 1 ETH to deploy.

We were using Truffle to test. Achieved 97% code coverage.

Testrpc. Mining a lot of blocks.

Testing code based on temporal logic, number of blocks, e.g. you want to protect funds for 90 days or so.

Can achieve same result with 20/30 minutes of blocks.

This kind of testing is really slow.

', - 'How do you handle testing?': '

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.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '93': { - 'Name': 'Rick Dudley', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

I worked on EthPM briefly.

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

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Lack of people over 40 – naivete.

Trust and guarantees – which crypto gives you which guarantees?

The claims of Ethereum – what features are worth preserving.

Contracts are immutable; but state is mutable –– contract code being mutable doesn’t give you any security. -> immutability.

Is the RChain application model (not Turing complete) better than having a Turing complete VM?

We haven’t been super happy with ganache in particular.

', - 'How do you handle testing?': '

I like the DappHub stuff; but it’s not fully integrated.

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.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Bottom-up sharding scheme

An app-sharding model.

Put a market-based order based on parameters on what validators you want.

Active bounty is a hybrid between a consulting contract & a bounty?

With Github, you have the opportunity to watch source code writing (commits) to deployment on mainnet –– the whole process cryptographically held together

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '94': { - 'Name': 'Evan Van Ness', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Have only ever played around very early, but never built anything seriously

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

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

It’s tough for everybody in this space to balance the “Wow, this will change the world” with the “Wow, this is really nascent tech”.

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Let’s talk a little about why you’re skeptical of fat protocols?

Never met Joel Monegro - hear even he doesn’t agree with the way people interpret his article.

Same day as his “there’s no such thing as fat protocols,” Jake Brukhman wrote Fat Protocols is Not an Investment Strategy.

In the very long run, this is a kind of database that will get commoditised. There will be parts that are decentralized, parts that will be centralized, public, private. No reason to think the protocol will always be where value accrual occurs

What opportunities exist or others to get involved in the community?

Transcribing calls - core dev, plasma, sharding, etc

do actual UX reports and write them up well.

Monthly and daily newsletter that are out there and could also be improved.

Plenty of technical builders are frustrated because their projects don’t get the attention they deserve. Helping those teams with marketing is really necessary and could be bountified.

There are other projects have developed languages that compile to the EVM that are more safety focus and not entirely clear on open sourcing them because they are worried about maintenance.

More general problem of people open sourcing tools that they don’t really want to maintain - so bountifying those important projects is a possibility.

Having a financial reward can actually hinder people if the work is creative. Only really helps when there are pretty clear guidelines and it is more a problem with motivation.

What is your general strategy to getting involved in the Ethereum community?

Anybody can start a podcast and there are A LOT of interesting stories to tell in this space because we’re all a little weird.

Especially if you put a bit of effort into the editing part!

Considers the newsletter a “tool that helps people be more productive”.

It’s really interesting that there are non-coding things that can achieve this effect and figuring out others would be really great community-based work for non-technical people to do.

Same thing for writing simplified versions of some of the technical papers and research that is being produced, a la Beige Paper

There are lots of different lists of info, sometimes up-to-date, sometimes not. People at Consensys have put together a list of all the developer tools, which should be opened up at some stage soon.

A lot of this stuff is ephemeral. If you don’t see the announcements and use things within a few weeks, they can often slip off your radar.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

NexusMutual - on chain smart contract coverage - risk coverage for your solidity code. It’s very necessary for the ecosystem right now. Goal is to become a thing that is seen as as necessary as a security audit and a bug bounty program.

Scaling is getting closer! FFG is pretty exciting.

Prediction markets are still exciting (but we all keep saying that).

We definitely need to keep iterating through compensation and incentivisation for working on public infrastructure, And making it such that people can open source their stuff in such a way that they don’t then forever need to spend the rest of their time maintaining.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

All the information used to be on Reddit, and there were some Skype channels for the people more deeply involved.

Part of the reason the newsletter takes so long to curate is that news has decentralized

Used to joke that the newsletter is just copying links on reddit

Spend a lot of time finding things in twitter.

A lot of new projects don’t know that r/ethereum is the main gathering place for the community.

Doesn’t touch on East/West divide of the community.

I feel like I have low visibility into the Asian ecosystem.

One of the brilliant insights from Vitalik was to go and spend so much time in Asia to make it a global thing, but there is still a lot more work to be done on that and in connecting the communities in general.

Translations are always a big part of this.

', - 'Are there any other questions we should be asking?': '

There are a lot of people with tools for themselves that are not well maintained.

There is some solution space out there where that gets solved and we need to find it.

' - }, - '95': { - 'Name': 'William Entriken', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Started using Ethereum in December.

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.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

The #1 problem:

My mom wants to buy ETH. In order to do this, she has to go to Gemini, give her SIN, give access to webcam, and access to their bank account.

Biggest bank in this ecosystem is Coinbase.

Every ICO is “illegal”

Need a new crypto bank. This bank needs to solve two huge problems:

Identity management (provided by the bank themself).

Anti money laundering

The #2 problem:

Solving KYC / AML for the general population, is understandable, and secure

Couple solutions like <$300 transactions lets you avoid AML restrictions

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Lack of private/business incentive to solve Bank/payments, not exchange, problem in crypto.

The ERC process:

Bring initiative, there’s forks, solve the problems –– being polite, being political, making phone calls to reach consensus.

Problems:

Problem #1: Ethereum is centralized. Code / governance is handled by one party.

This is the “EIP” process.

These aren’t technical reasons, they’re political reasons.

The EIP process:

Anybody writes an EIP – must be technically valid, describes a change to the Ethereum ecosystem. “I want a sidechain”, “i want to change the gas for this opcode”, etc

If the EIP is implementable (i.e. it compiles), it’s accepted as a draft.

If there is community support, it’ll be reviewed by all core devs.

If it is supported by core devs, it is implemented.

If people support it, then people will upgrade the clients.

How it actually works:

You publish the EIP. There is a storm of discussion; emotional, backhanded.

Blackballed for mentioning cultural/political taboos

PR is not the right word for it. More like a wiki.

They discuss it at the core dev meeting. They implement the code, clients upgrade it.

Someone puts it on Hudson’s PM meeting agenda

How Swift (from Apple) handles this:

You go to the mailing lists, you start a discussion.

This takes a lot of effort, so you wanna be sure your stuff is legit.

Big discussion in the community. Swift is centralized (one party). You need code already, a test case or something, you explain technically in-depth. You get it to review, 2 week review period, it’s posted on top of Apple Swift website + goes out to mailing list.

The key point is: the 2 week speed pump. Everyone has to pass through that.

How DARPA handles bounties

Here’s a very specific problem and you need a 100x improvement

Come up with working solution that can support network of 10k

If you can do it elegantly, here’s 50k and we’ll study it further before implementing

The community expects full-time people; they don’t cater to part-time contributors.

A contributor needs to look at all issues and PRs –– there’s no queueing system. One could get approved at any time.

The ERC process:

Write an interface for a contract. He wrote 165 and 721.

A ton of new token standards.

First mover advantage to writing standards/interfaces - something like street cred for devs.

Over-standardization occuring

Not enough focus on what people would actually want/need to use

I don’t see the need for a package manager, the existing tools seem adequate.

Not enough money allocation from teams to bug bounties.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '96': { - 'Name': 'Christopher Goes', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Wyvern is an application agnostic protocol for exchange of transactions, not tokens

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

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

Solidity - I find it difficult to write complex, high-assurance code vs Rust/Ocaml etc.

Wyvern uses large exchange core contract

System of several contracts (delegate calls) needed to validate order

I wish there were easier ways to use typescript rather than javascript with solidity. Calls to the contract (from javascript) are mostly untyped. I definitely want better statically typed testing tools that are clear and easy to use.

', - 'How do you handle testing?': '

Oyente

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

', - 'What tools don’t exist at the moment?': '

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)

', - 'Other domain specific questions?': '

What are the barriers to Wyvern usability (by relayers) and liquidity?

Wyvern is an exchange contract, not a platform

Platforms will diverge in their purpose

Openseas could use Wyvern

Economic model set up which they could take fees. Can be used by relayers to take fees in Wyvern orders

Would more expect relayers in different verticals, more

Wyvern makes it easier to share liquidity (between relayers)

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Introduction to Ethereum Medium post: https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369

EVM yellow paper, Solidity documentation

Edge cases can be super technical - go look at the hardcore docs if you really want to know. There are no easy answers for some things, after all.

', - 'Are there any other questions we should be asking?': null - }, - '97': { - 'Name': 'Matt Condon', - 'How do you handle smart contract verification and security?': '

Nothing, no real process besides following best practices.

Gets auditing. Should be running Mythril but hasn’t set it up yet. They have a great blogpost on finding unchecked self-destruct.

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Built a raffle contract, but didn’t ship it because I didn’t want to deal with real money in early 2017

First thing I shipped was steak.network

Now building XLNT and gnarly

Solidity contracts.

Off-chain clients.

Frontend interfaces for blockchain-backed stuff.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': '

Iteration cycle is slow, especially compared to webdev

No visibility into errors in solidity. No error logging, no line numbers. Complete black box.

People end up commenting out lines, deploying testing, re-editing just to figure out bugs.

Needs to be fixed at the EVM level.

Logging is undefined. don’t really know how you’re supposed to log even though I have read all the docs.

The solidity inheritance interfaces are weird. Really likes Bamboo for this reason.

Ganache fixed a lot of testrpc issues. But it doesn’t support websockets so that’s annoying. But at least you can actually use geth in dev mode now.

Are you running into problems with any of the following:

Gas limit: Yes, in general.

Off-chain computation: Yes, open problem for TrueBit. There’s gotta be some best practices for setting up state machines and stuff like this.

State Channels: Haven’t used them.

', - 'How do you handle testing?': '

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.

', - 'What tools don’t exist at the moment?': '

Truffle has a lot of rough edges (documented elsewhere)

Gas profiling

Interactive debugger that works

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Mental model of how blockchains work. Also mental model of how Ethereum works.

I wrote an article called “Getting up to Speed on Ethereum” that answers the vast majority of question I had when starting.

Tokens are just numbers in a database with an API to add and subtract. Not some native object or something.

Solidity the language, besides its quirks, is not hard to learn. The hard part is understanding the environment it’s executed in, and what that means for your program

What would be the hardest part of teaching a software engineer to build a dapp?

“Solidity is just like javascript” - THIS IS SO LOADED WITH WRONG IMPLICATIONS

People’s understanding of web development doesn’t really transfer

Software engineering principles transfer, but it’s not just web development.

', - 'What are you most excited about in the short term?': '

Biggest hype tech is token-curated registries. Curate a set of things such that the resulting registry is more valuable than the sum of its parts. Use that to create economic incentives around rational behavior for the curation process.

E.g.: machine learning if you want to create public images for a dataset

E.g. structure government as a token curated registry where laws are curated into a constitution. If someone thinks their expertise will increase the value of the constitution they can become a curator

Mostly interested in 2nd layer projects that don’t exist for crypto’s sake

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': '

All of the people in Cape Town that I just met.

' - }, - '98': { - 'Name': 'Ramon Recuero', - 'How do you handle smart contract verification and security?': '

Found a list of the top 10 security vulnerabilities; reentrancy, math overflow, ...

You don’t know what you don’t know.

How to find info:

Google / reading about the DAO hack / Reddit.

', - 'Other bounties?': '

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.

', - 'Who are you and what are you working on?': '

Last summer, developed Redis on Ethereum. Simple to read & write data.

', - 'What are the tools/libraries/frameworks you use?': null, - 'What are your biggest frustrations?': '

Was pleasantly surprised with Truffle - testing was easier than expected.

What was hard:

Debugging. Solidity compiler error messages could be better.

There’s no console.log, can click and step into the code.

Google and Stack Overflow are often the best resources when running into bugs.

Trial & error, until you get through it.

It’s difficult to communicate this to other people.

Getting the mindset for developing for the blockchain is hard.

Hard to remember,even harder to explain to other people.

Deploying to testnets and mainnets was hard.

Had trouble with gas.

Getting Ether on the testnet. No faucet.

Found developer on Reddit Ethereum thread.

No chance to update the contract. Just pushed new contracts.

Eth npm in the beginning.

Different ES6 configurations in front and backend

', - 'How do you handle testing?': '

Redis had the smart contract. Made an npm library; had Truffle tests + npm tests.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': '

Testing in Truffle.

Is simple if you come from the Javascript world.

Metamask.

', - 'Who are the other people you think we should talk to?': '

Blockchain Berkeley Lab – professor – working with students learning blockchains.

', - 'What are the best educational resources?': '

Did Coursera course to implement blockchain, but it’s likely not the best.

', - 'Are there any other questions we should be asking?': '

Share your learnings, get the community back in, and do another iteration.

' - }, - '99': { - 'Name': 'Facu Spagnuolo', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': '

For governance:

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.

', - 'Who are you and what are you working on?': '

I studied Computer Engineering and am a full stack dev. I started my career by programming web stuff and distributed systems.

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!!

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Speed of testing in Truffle is taking ~15min and it should be 1-2 at most. We need to speed that cycle up badly.

Ropsten is really slow when we need to test something in a “real” network. We have needed to cancel manually our own transactions and follow many rabbits down many different holes to figure out what happened. We need a better, more realistic testnet, for all our contracts.

You can’t set breakpoints when debugging contracts, or end-to-end transactions on the network and this can cause you to lose the whole day when you miss something as simple as a flag or a param in a contract etc.

No easy way to log things in Solidity, which makes missing the stuff above much easier than it should be.

The linter tools also take too long. It should just be possible to install and run these sorts of things without needing to do any config of your own, which is not currently the case.

Solcoverage has to be set up manually, and the docs kind of suck around this. It took us a long time to figure it all out for ourselves.

Plain solidity console/interpreter to test your contracts where you can play with the types, variables and scopes without needing to recompile everything.

Volatility of the markets - really hard to convince people to join and use the currency because of this.

Legal issues around launching companies and products are a real PITA. We need proper DAOs and soon.

Came out of web dev industry, and it is really mature. They have a lot of methodologies for running projects and organising teams. Most people in Ethereum are very young and these sort of processes are generally a mess.

There’s a lot of pressure on the back of the price, and this or that ICO and we need to make sure that the community supports and contributes to better, clearer, slower processes that actually achieve the desired goals rather than cutting corners to ship not-really-decentralized products.

We need to figure out some new processes too unique to the problems we face in crypto.

', - 'How do you handle testing?': '

We use Travis CI.

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.

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': '

Upgradable smart contracts?

We’ve been exploring many different approaches over the last year, all of them using proxies: i.e a contract using a delegateCall opcode to make things happen.

Biggest problem: we had to store information about 2 different domains, 1 of them being the proxy information and the other the contract that needs to be upgraded.

Proxy information: delegates each call to implementation contract. Storage in proxy contract, logic elsewhere, so not something new (Parity also uses this pattern).

We don’t see how upgradability works without some kind of mechanism for governance: the proxy needs to ask someone/something if the contract can/should be upgraded. This information needs to be stored as well: the “owner” and the implementation details.

The way solidity manages storage, the contract that was going to be upgraded needed to follow the storage slots where the proxy was saving the relevant information because it is important not to overwrite them.

We found a final approach that manages this very elegantly: using inline assembly to store variable and bypass the way solidity performs its own checks. We are using storage slots that solidity will never be able to access, which is how we can ensure our approaches are really safe and that we can have upgradeable smart contracts that don’t overwrite important information.

Why should we even have upgradeable though, if immutability is such a big thing?

We really don’t think upgradeability works without governance.

We have storage in one place and logic in another. So the storage actually remains immutable and will never forget what is put into it. We can modify it, but that is part of the history and you can inspect those modifications easily if you like.

We are not leaving immutability then, just handling it in a smarter way.

The idea came from exploring the strategy Solidity itself uses for mapping of variables, but with some delta to make sure Solidity won’t overwrite things.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Zeppelin OS!!

Really excited to see a lot of projects on mainnet.

Decentraland, Aragon and Status are the most exciting.

Interested by Cardano: they have a really different way of writing smart contracts on a blockchain and we can learn a lot from them. They also have a really good team, which is always a good lense for me to assess projects through.

Neo is another interesting project. Haven’t used it yet, but met them at a conference and they were really focussed and clear about what they are going to be doing over the next little while.

Cosmos is really interesting! It’s really huge, but I am excited to see what happens there.

Plasma, eWASM, state channels - all these things are going to be exciting to explore more.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Fran Giordano from Zeppelin - knows a lot about the EVM especially.

Alejo Salles from Zeppelin - worked with quantum physics, neuroscience and AI. Mind-blowing.

', - 'What are the best educational resources?': '

People in zeppelin are the best resources I have!

One of the things I love most about Ethereum in general is the community, so we try to get to know as many other projects as we can and collaborate with them. This is a great way of finding quick answers to hard questions and getting an overview of the best current tools available.

Google, ethereum stack exchange too. But the community is the best resource we have.

', - 'Are there any other questions we should be asking?': '

I would love to know how people got involved and how they managed to be where they are right now: i.e. what path did they walk to get to where they are now.

I would really like to know if we are all doing the same things to get to where we are, or if there are smarter ways to grow quickly without losing culture/vision. Sometimes it feels like we’re all alone in the jungle, struggling to survive, and it would be awesome if not everyone had to feel this way going forward.

Would also be helpful to see how other companies are organising themselves on a day-to-day basis and how they collaborate with other teams, with remote workers etc.

' - }, - '100': { - 'Name': 'Manuel Araoz', - 'How do you handle smart contract verification and security?': '

We design first then develop.

Sometimes they see other teams mix these two phases.

This is bad, because you can break your assumptions in nuanced ways..

', - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Open Zeppelin: open source smart contract framework

Currently working on building web app

On chain libraries with upgradability

Contract interaction

Marketplace

Scheduler for asynchronous execution.

', - 'What are the tools/libraries/frameworks you use?': '

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

', - 'What are your biggest frustrations?': null, - 'How do you handle testing?': '

Truffle automated testing with javascript unit tests

Migrated to async/await style of tests

Mocha, Chai

Onchain bug bounties for finding implementation bugs.

', - 'What tools don’t exist at the moment?': '

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].

', - 'Other domain specific questions?': '

Interesting: Solidity compiler team runs OpenZeppelin tests when they update & other projects tests to make sure they’re not breaking.

', - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': null, - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Jorge from Aragon.

Kevin Owocki from Gitcoin.

Other Zeppelin devs: he will make intro.

Esteban from Decentraland.

', - 'What are the best educational resources?': null, - 'Are there any other questions we should be asking?': null - }, - '101': { - 'Name': 'Brendan Chou', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

On chain derivatives for erc-20 tokens

Open sourcing their code in next week or two

Only smart contracts protocol so far, no UX/Dapps

', - 'What are the tools/libraries/frameworks you use?': '

Remix for smart contracts

Writing Javascript tests

Truffle for compiling and test, NPM to manage packages,

SolCoverage

', - 'What are your biggest frustrations?': '

Running tests in Truffle doesn’t show you why/where it reverted

Must search through binary instead

TIME uncertainty (for interest rates). Given that time is discrete on chain, it’s hard to determine the interest rate at a given block, and it gets even harder when you think about how to do that in as decentralised and trustless a way as possible.

Not being able to run untrusted code. If a borrower goes to repay a lender, it would be nice if that borrower could call a function to notify the lender to run arbitrary code in a safe way - maybe an obscure design pattern though.

Sending ERC token allowances are annoying.

Changing token standards is difficult but may be necessary (see ERC 233 and 277)

Creators and owners currently have control over smart contracts, not truly decentralized

>0 less efficient than !== 0 due to Solidity handling of ints. These kind of edge cases in general are difficult to learn about and it is only really by writing contract yourself and testing them endlessly that you discover stuff like this.

Doing floating point arithmetic on chain, using Euler’s number, e, and other fun things (30,000 gas, not too expensive which is awesome).

', - 'How do you handle testing?': '

Mocha, js unit tests on Truffle

', - 'What tools don’t exist at the moment?': null, - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

Anything that helps us iterate faster. Tests currently take ~20 min. Currently doesn’t run more than one ethereum node per computer. Could be cool to split up tests on different ethereum nodes.

If you modify contract that inherits from another, you have to tell truffle. End up recompiling often.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Solidity readthedocs, stack overflow, google searches etc.

', - 'Are there any other questions we should be asking?': null - }, - '102': { - 'Name': 'Lane Rettig', - 'How do you handle smart contract verification and security?': null, - 'Other bounties?': null, - 'Who are you and what are you working on?': '

Core developer for EWASM, but independent and works on a grant.

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

', - 'What are the tools/libraries/frameworks you use?': '

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.

', - 'What are your biggest frustrations?': '

Testing - “is a nightmare.” The way it is done at the core level is very overcomplicated and confusing.

3 types of tests and completely separate tooling for each

State - honestly don’t know, even after several months

VM - lowest level, see what effect a tx has. Not documented well

Blockchain - wait for blocks to be mined and stuff to happen.

Historically made sense to do this. Each client has to pass all three types of tests so that we don’t end up with consensus bugs.

Documentation is non-existent and tooling sucks.

Would be great if there were a single command to run all the tests.

How do I run a single (VM) test easily? Or even just an arbitrary subset of tests? We use CI tools to run them instead (Travis, but are transitioning to Circle). It’s all dockerized, so getting tests to run locally is very difficult.

There is a tool called testeth, built in cpp-ethereum.

Test tooling should be in its own repo! Not maintained very well either.

In order to run testeth, I have to download and compile cpp-ethereum.

Worth having CI as its own separate point as it is the other biggest headache, along with testing.

Communication tools in the EWASM team - use gitter currently. No threading, images etc, basic stuff that is missing.

EF uses Discord internally and there is an #ewasm channel there, but we have team members who are not part of the Ethereum Foundation and are not on Discord so we need another channel.

Setting up bridges is a possible solution that seems to be working quite well for other teams.

Testeth is a great place for bounties and should NOT BE A PART of cpp-ethereum

Getting testnets up and running - there should be a test network in a box that we can just deploy at the press of the button It should not require a devops engineer to handle this kind of stuff.

There is a half-baked interpreter for WASM in Go and C++, but we need one in python so that we can plug into Trinity (the new Python full node implementation that is being written from scratch and is the vehicle for research including sharding).

', - 'How do you handle testing?': null, - 'What tools don’t exist at the moment?': '

Working on evm2wasm in JS - we need to be able to run all the tests using the new WASM infrastructure. I want something like a CI on my local machine, make a change, save the file and see whether the tests are passing or failing. Hot reloading for the whole test suite kind of thing. Local test harness that just works.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': null, - 'What are you most excited about in the short term?': '

WASM allows people to write contracts in non-EVM specific languages: C++, Rust, typescript etc.

Bring on an order of magnitude increase in the number of devs.

Working so closely on Aragon because of the work being done by everyone on governance

FOAM is going to open up the whole world if it works as they say it will.

Truebit is amazing.

TCRs

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': null, - 'What are the best educational resources?': '

Solidity tutorials on ethereum.org was the place I began. Needs to be updated and Hudson is working on that. It should be the definitive source in the sense that it’s the first place people studying Ethereum often land.

Has to be about pair programming for me when it comes to core dev. There is no documentation and it lives inside the heads of core developers. There is a repo for WASM stuff, but it is a moving target.

', - 'Are there any other questions we should be asking?': '

Product management mindset is incredibly important. Ethereum full node software is quite clunky and is not user friendly. Would love to see projects further down the stack actually adopt this kind of mindset.

Do you know who your users are? What sort of feedback loops do you have with them? How do you talk with them? Have you done user needs analysis?

Communication tools are interesting to dive deeper into - both internal and external.

Governance and signals is very important to me - how do you get a sense for community consensus? Build things that reflect the collective will of the community, but we don’t have access to that. What signals would you like to be able to get from your community and how?

Concept in medicine called “practicing at the top of your degree” - doctors should not be scheduling or handling payments. Devs shouldn’t be worried about devops, finances, scheduling.

What % of your time today are you spending practicing at the top of your degree/qualification? Talk about processes especially.

' - }, - '103': { - 'Name': 'Kames', - 'How do you handle smart contract verification and security?': '

The mainnet launch was very minimal. Using segregated accounts in uPort app, use proxy contracts that have been around like a year. These went through formal verification a while ago. We were confident with putting them on mainnet. Switching up in the future how we handle it.

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.

', - 'Other bounties?': '

Education platform that is not focused on a business model. Loom is doing a fantastic job of educating people, but it’s a business. A great general education source that is not leading to some business. Online university or online education center would be fantastic.

Better UI/UX, thinking about this next layer. Get product people, designers, etc. involved. A Material design for dApps.

', - 'Who are you and what are you working on?': '

I am working on uPort as a community a manager. The primary role is basically discovering how to empower developers to use uPort. uPort is a decentralized identity system.

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

', - 'What are the tools/libraries/frameworks you use?': '

Eth.js, we use Nick Dodson’s stuff. Inject web3js, but use more of the lightweight stuff for internal requirements. We use Truffle for tests. For the Buidlbox project, we use React-Redux. Mobile app is all react-native. Use React/redux everywhere, React sagas.

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.

', - 'What are your biggest frustrations?': '

Personally, I don’t have that many frustrations. However, Solidity has a lot of updates every time and has a lot of breaking changes. It’s difficult to manage this. EthPM will help this.

As a team, working distributed on a lot of systems that are new is pretty tough. But have a pretty knowledgeable team.

Still deal a lot with the JavaScript ecosystem. Heard web3js was garbage, not having promises and heard it wasn’t great. Heard Ethers.js was good, supported by Richard Moore of the Ethereum Foundation. Would be great to have education that there are other options out there beyond the most popular projects

Eth.js from Nick Dodson is super bare bones and super modular, Ethers.js is a bit more built out by Richard Moore.

I dibble dabble in smart contracts, I do a few demos with things like token staking for events. But I am mainly in the web 2 stuff. Not necessarily building out infrastructure or production ready contracts, more of showing the general web3 flow.

Would recommend to redo Remix, want to share code from Remix. From Remix, be able to push GitHub. More of a collaborative Remix, better UI.

', - 'How do you handle testing?': '

We run a lot of unit tests on the JavaScript, but don’t do enough testing right now. For smart contracts, reach out internally at Consensys. But not baked out process. Could use a better audit process.

Could use a better audit tool. Can test smart contracts at a code level, formal verification but haven’t researched this.

', - 'What tools don’t exist at the moment?': '

Drag and drop website builder for dApps, I’m working on this. Product people are not able to prototype the user experience is very detrimental to the long term growth of the ecosystem

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.

', - 'Other domain specific questions?': null, - 'What was the hardest part about learning to develop with Ethereum?': '

Wrapping the head around everything in the ecosystem. Because Consensys is such a big force it’s easy to focus only on Consensys spokes, but there are a lot of other solutions out there. Yesterday someone posted an alternative to Truffle but hadn’t seen that before. Having a clear understanding of people in the ecosystem.

A library of all smart contracts, background of these smart contracts along with user stories. A better understanding of existing tools. Search and get 5 different options for events smart contracts, or a decentralized exchange. See instantly these.

', - 'What are you most excited about in the short term?': '

The overwhelming amount of events. ETHGlobal is doing a great job with hackathons worldwide, short term and long term benefit. More and more outreach and pulling more and more people in.

', - 'Was anything easier than expected?': null, - 'Who are the other people you think we should talk to?': '

Linnia, they are doing market dataplaces for your data. Figuring out how they can build this out in Ethereum.

', - 'What are the best educational resources?': '

Loom’s CryptoZombies and their general onboarding process, this is very approachable with good design and good practices. They’ve taken a big focus on not just focusing on the code but focusing on the experience. Not good to throw encyclopedias at people. Truffle sits in the middle, they have good docs. Ethereum itself is pretty difficult to parse their docs.

Designing for intermediate JavaScript developers could be very interesting. Catering this education experience better.

Just looked at smart contracts long enough, wasn’t super intimidating as they are designed to be simple. Looking at Zeppelin, looking at best practices, understanding this stuff. But now want to get more into bytecode stuff.

Lack lower level knowledge of how to super optimize a smart contract. Want more code to look at to get at optimizing bytecode.

uPort will be focusing on education, more videos to help these intermediate programmers.

', - 'Are there any other questions we should be asking?': null +const InterviewData = { + "0": { + "name": "Fabio Berger + Remco Bloemen", + "who_what": { + "question": "Who are you and what are you working on?", + "answer": "

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