I’m concerned that the need for security and correctness in smart contract engineering is being outweighed by the pressure to deliver highly complex systems to anxious ICO investors.
Following conversations at EdCon in Toronto, there’s a clear need for a gathering specifically focused on smart contract security. Here is my best attempt at outlining what I think this event would look like, as well as my open questions.
Goals
To share knowledge to prevent and mitigate security risks facing smart contract systems. I’m particularly interested in anything that improves the working relationship between auditors and developers, and the outcomes of working with a security audit firm.
Topics
For best results, the scope should be well defined, and strictly enforced.
in Scope
Secure development lifecycle
especially how auditors can work with developers earlier (not doing security at the end)
Auditing standards, techniques and best practices
Security analysis tools
Formal verification in practice
Risk mitigation
Upgradeability
Running a good bug bounty
Out of scope
Protocol governance
Security of protocol client software
Crypto-economics and game theory
Product/service sales pitches which are not educational, or fre
Event details
Timing/Location: August or September, at a time coinciding with another major event which would attract the right audience. ETHBerlin is a good candidate. It should be before, or after the primary event. Not concurrent, or as a sub-conference.
Attendance: Attendance should be skewed towards the security community, with healthy representation from high quality developer teams. I think this should be small-ish, in the range of 40 to 100 attendees.
Format: I really don’t know. An unconference format might work, but I’m least opinionated about this, and think it will figure itself out during the organization process.
Open Questions
What’s the right format?
When/where should this happen?
Can the goal and scope be refined?
Who can help make this happen?
I can help by reaching out to the security and dev community, provide input on curation, facilitation, topics of discussion, etc.
I do not have bandwidth to organize logistics, or the kinds of activities the require a lot of quick email response.
ETH Berlin would be a great candidate for this conversation!
SecurEth would love to take point on organizing the logistics for this discussion. We were discussing a public forum discussion or “unconference” focused around sharing our community members’ “best practices” with each other, with a short presentation on the SecurEth guidelines we are creating for the wider Ethereum Community.
We pictured it being similar to the UX/wallet “unconference” from EdCon. It was definitely a very successful discussion, with targeted topics focused on problem solving in this space. The smart contract development community needs more focused discussion of our problems to enforce more secure design overall.
For format, I suggest you create a planning wiki – where people can start announcing their attendance and the things they want to talk about. @jpitts can press a magic button to wikify this post.
“Unconference” means you have people show up, pitch their topic of interest at the beginning of the day, and then slot it into open slots / spaces during the day.
A blend, where people self-organize ahead of time on wikis and get dedicated slots, and then leave room for day-of discussions.
I think the other learning from walletconf was WAAAAAAY more open time for digging in and having extended discussions, and then breaking out into working groups. Including pair programming, demos, whiteboards – whatever is needed. More working sessions, less presentations.
We still have to do work on the Summer Magicians meeting for what an agenda looks like over two days.
Day before / day after ETHBerlin so it doesn’t overlap with “main” activity would be good.
@maurelian great job in clearly saying that you can’t do lead organizing duties. So – ask for volunteers. This might come from a company that has bandwidth of some people internally or an individual.
I am happy to help support a lead organizer in figuring out / iterating “how to run working groups” – especially as this event gets planned in parallel with the Summer Meeting. If anyone wants to have a “live” discussion, lets use the Berlin gitter room for now (ahead of an “events” room) --> https://gitter.im/ethereum-magicians/berlin-council
Hi there, MP from Golem organizing ETHBerlin here.
Sent this to @maurelian but writing here to propose venue.
Here you mention that you cannot host it during the event, so as I got a membership at Full Node (the coworking space by Gnosis & Cosmos), and we will have the event space available, I am happy to book this for you and help out. In that way, ETHBerlin as an entity would be out of the gathering, but you would have all the Hackathon participants around.
Update: Capacity of Full Node’s event space is 150 standing, 80 sitting.
Will follow up on this, I think the “working group” thing may be slightly different for this gathering than walletconf, since the solutions to these problems are more processes and procedures than building new software. But we can definitely explore different tools and options, create broader exposure to what’s out there.
I think it’s important that a neutral third party leads an event like this. Please correct me if I’m wrong, but there might be more politics at play here because audit firms are competitors and the solutions being discussed here have a high impact on the community as it hopefully sets standards for the community at large. That is a big part of the reason we are volunteering to run the event, as our organization is neither auditors nor developers.
It may not be a big deal now, but we believe small things set early have the chance to balloon into larger issues if a balance isn’t set early.
You make a good point about a neutral 3rd party, and if one is available to lead, that is probably ideal.
Though IMO it’s reasonable for help, and input to come from many places. ConsenSys “marshalling resources” doesn’t mean making it a branded event, and there are certainly a lot of ways we could be perceived to overstep our bounds… especially being, y’know… ConsenSys.
But I also think this should have a fairly “For Us, By Us” feel, so input from a number of auditing firms is needed.
Absolutely! Definitely appreciate help and resources!
I was talking with Fredrick about this and how to ensure everyone feels like they have equal say. We’re modeling SecurEth after aerospace groups like ARINC, which operate more as a trade group composed of a consortium of players in the ecosystem (Boeing, Airbus, etc.)
Without ARINC being a separate organization with a governance process, the tendency for larger Industry members to drive standards towards anti-competitive practices in the long run not only hurts competition, but makes the standards weaker as a result. Smart Contract Development is still extremely young and growing field, so true competition is not a thing yet, but our experience is driving us in this direction to mitigate the problem before it happens.
Hey, Matt from ZK Labs here. Happy to contribute resources as well - not logistics/operational, but review/curation, coming up with content, up for doing a talk, etc.
In terms of topics I would also suggest covering the game theory or mechanism design angle, code can be correct logically but have unintended consequences in an open system. I think this is under-appreciated in the current smart contract mindspace, even by the security community.
That’s an interesting thought. The game theoretical analysis is something that should be included in the specification (in my opinion) and explain how the different assumptions being made play into the design and lead to different outcomes in the code. Being able to quickly appreciate the design from this angle is definitely a part of the audit.
Whether or not that design will actually meet it’s goal is really something external to an audit. I think that’s a different skillset, which requires simulation results and data analysis of real-world data to confirm. Auditors can only confirm logical consistency and correct implementation of the mechanism ultimately, unless they really want to get in the weeds on the design. This is ultimately the “secret sauce” the designer brings to the table, I think for an auditor to do their job, they can safely assume the mechanism is well-intentioned.
, some people from the Aragon team would love to attend.