ETH Berlin Unconference Workshop Topics


#1

We are looking to split the unconference into 1.5 hours of lightning talks in the morning and workshops around community chosen topics in the afternoon. This thread is meant to act as a repo for potential workshop topics. If there is something you would like to talk about or work through as a community, please post below! Topics discussed at the unconf will be chosen in the process described here: https://docs.google.com/document/d/1TJiCfBrzRD0qGs7JL8BVPABCcBDLdRfhWUle7uPbj-c/edit?usp=sharing


#2

Hey, I’ve been leading some workshops about learning how to audit ethereum smart contracts. So far I’ve covered common security vulnerabilities and other info about how to approach audits from a mindset standpoint. Next workshop we’re focusing on running Mythril and Oyente tooling against Ethereum Solidity code. Would love to combine the two into a workshop / lightning talk here. Providing the links for 1) video recording of previous workshop about learning how to audit ethereum smart contracts https://m.youtube.com/watch?feature=youtu.be&v=DkVpUqzU8SI&t=90 and 2) the link to sign up for the upcoming auditing ethereum solidity with Mythril and Oyente workshop. https://www.eventbrite.com/e/auditing-ethereum-solidity-smart-contracts-with-mythril-and-oyente-tickets-48005502751


#3

Thanks David! This event will be with a group of your peers. If there is a demo of a tool, it will likely be from the creator. However, “The auditing mindset” might be a good workshop topic to discuss the approach of different auditors. What is actually discussed in the workshop format will be decided by the community on the day of the event. This thread is meant to gather all the possible ideas that might be discussed. E.g a 721 Audit stamp, Security guidelines for developers, insurance for an audit, an open source auditing fund, etc.


#4

“Ensuring adoption of secure development processes”

Basically, what ideas help or incentivize developers to write better code. A few of mine:

  • Smart Contract Insurance (better quality -> lower risk -> lower premiums)
  • Guidelines (better knowledge sharing, industry wisdom)

#5

I’m interested in discussions of incentive alignment between developers, auditors and users. Ie. Should auditor’s risk be limited to ‘reputational’, or should we have some skin in the game?

This of course ties in with on-chain mechanisms for signaling commitments and confidence, like TCRs and prediction markets.


#6

I like the idea of lightning talk to give everybody the opportunity to comment. I think there should be more time than one hour for this. I would love to hear a lot of different opinions from different people.
We would like to give a lightning talk about the treatment of unit tests in smart contract audits. We conducted a meta audit on this issue and we strongly believe that test are not looked at enough in audit. The title of the talk would be “Good tests => Good code” We´ll be comparing how audits are currently done with our vision of an “ideal world” and derive some best practices from our research. This topic also touches a whole class of easily preventable bugs
like typos and tools developer and auditors need to write proper code.


#7

My 2 cents: No skin without control. Auditors make recommendations. It’s up to owners to decide whether and how to follow them. “skin” is a function of “authority.” If I can’t decide, unilaterally, to do things on your behalf to make you safe, then I can’t really get blamed if things go sideways, right?

This same debate happens with CISOs in industry, where even they are not held accountable for failures of their organization because ultimately it is the CEOs job to balance risk, and only the CISOs job to make it transparent how much risk you are taking and then work to reduce it (within their means/budget).


#8

Right, and if someone is being reckless, we shouldn’t vouch for them. Ideally we’d even make that transparent.

This makes sense, and is valuable perspective.
But… it’s also part of what’s so broken about modern security. The CISO at Equifax answered to the CEO, who answered to shareholders. No one was incentivized to be transparent with the customers.

In Ethereum, source code can be published and verified, so the initial condition, and expectation is transparency. If audit reports are going to be used for marketing, auditors need better tools and avenues to clarify what the audit really means.


#9

The CISO at Equifax answered to the CEO, who answered to shareholders. No one was incentivized to be transparent with the customers.

To be fair, those people lost their jobs and board members were replaced. There was some accountability for Equifax’s security issues.

In Ethereum, source code can be published and verified, so the initial condition, and expectation is transparency. If audit reports are going to be used for marketing, auditors need better tools and avenues to clarify what the audit really means.

The typical issue with this approach is that individuals are either security experts or they are not. There is no real in between. Efforts at transparency typically fail because consumers are as likely to believe vendor FUD and snake oil as they are real, vetted truth. They are not sophisticated enough to tell the difference between the two. You can try to tell them that your transparent metrics are the ones they should believe, but ultimately the psychology behind what consumers will trust is hard to predict.

However, transparency is something very different from accountability where you started. I’d be happy with transparency, I’d just be worried that people start demanding meaningless measures of transparency, put their faith in the wrong indicators, and then start demanding that I produce them against my better judgement.


#16

Should we merge this with https://discourse.secureth.org/t/ethberlin-security-unconference-agenda-post-topic-here

I feel like we’ve split conversation on the same topic.


#17

This thread is meant to house ideas for workshops. The other thread is meant to house proposals for lightning talks at this point. That was the reason for the split, but if you feel we need to merge that is fine with me.


#18

Ah yes, I see it now. I think the other thread needs to be more clear that it’s lightning talks.

EDIT: Changed titles


#19

I’m particularly excited about these topics:

Secure Smart Contract Upgradability
-How to maintain decentralization when iterating on ideas

Signature Validation
-Role of EIP712?

Key Management issues
-Where to store ‘owner’ keys and ‘admin’ keys for contracts

Data Privacy/Security
-impact of GDPR on dApps


#20

If there interest, I would like to see a workshop around public benchmarks and tools for creating reports from them.

I will have something to demo: the projects under this github organization.

Things for discussion:

  • What people want to see in a report?.Suhabe has this while in my revision I have this, but what format and what information would be better?
  • Bench Suite meta data tagging:
    • What category of vulnerabiliites does the benchmark test?
    • Is it supposed to succeed or fail?
  • Related to the above: Guidlines for writing a benchmark suite, but this could whether the code is to be realisitic or to pinpoint and show off specific features
  • Documentation on the benchmark, e.g. It tests this so it needs to do that but note that…
  • How do we facilitate new analyzers, and new benchmarks under a single umbrella. Right now, that code is a bit git (submodule) and github oriented. I am assuming analyzers are installed, but if we used a common format for running e.g. a docker container then that could be accommodated.
  • How do we get this under the ethereum space. Should it be there?

And finally with respect to the work part of the shop rather than the discusssion, there is lots to do in that particular suite, either in adding analyzers, updating reports, creating better reports, and so on.

Alternatively people could improve the existing benchmarks, or write more. Hey, if you want to even write your own better suite of benchmark suites, go right ahead. (And if yours is better, I’ll contribute to that instead.)


#21

An example of some output is that if there are 20 people in such a workshop, and everyone commits to writing up 5 good benchmarks (with comments and explanations), then that’s 100 examples on the list and a good start to the benchmark.

Just as an idea for outcomes!


#22

This would be fantastic.

Some statistics on current two the benchmark suites. The Suhabe benchmark suite has 35 contracts. The (Not so) Smart Contracts has 19. So even at only 10 people with 5 benchmarks, or 20 with 3 benchmarks, we’d about double what we have right now.

Surely, long-time users of Solidty can come up with one interesting example of something they’ve encountered that is worthy of detection and isn’t currently detected. And personally, I would be happy even if that one were added.

Plus there is the benefit that others can look over the benchmarks proposed, hash out what’s good or bad about them to make the benchmark better, and possibly help document it.


#23

+1 for Key management issues
+1 for Data privacy/security/GDPR


#24

A few of us would like to have a workshop where we share documentation and map commonalities.
The idea is that there may be some overlap and guidelines for smart contract auditing could be derived.

  • Collect and comb through existing documentation and content
  • Categorize the documentation and content into rough relational groupings
  • Discuss common language between auditors/developers
  • Attempt to formalize guidelines for smart contract assessment

Looking for co-organizers

The full working proposal is here https://docs.google.com/document/d/1TgSmqgWOfukZo8EqvzdtPhPkzeV_ve0t4YtjaMo2jmM/edit?usp=sharing


#25

Our current workshop structure is:

  1. Deeply understand the problem: (Relentless Root Cause Analysis aka keep asking “y tho?” until it’s obvious)
  2. Sketch the solution well (what different pieces need to come together to solve the problem). This also includes understanding what’s out there and how to integrate.
  3. Define work group and work on research and development of the solution(s)

A few of the items in the above I would define as take-home work from the workshop i.e. stuff we don’t need to get in to during the event.

The most important thing is understanding exactly what problem(s) guidelines (or any other topic) solve, how it should solve it, and agreeing as a group how to move on from there.

We didn’t discuss this format in the meeting today, but I wanted to ask what people thought about it?


#26

I’d like to discuss how you can use insurance a second layer security mechanism, including how it can help align incentives between auditors, developers and users.

I feel like this is pretty broad topic, and while I’d be happy to run through our specific ideas (Nexus Mutual) in a lightning talk, hopefully a workshop would prove more valuable. Our ideas are just one potential way of achieving the end goals, so it should be just the start of a much wider discussion.