Title: Proposed_gathering_of_the_Security_community
Category: Working_Groups

Author: maurelian
Date: 2018-05-15T16:01:31.097Z

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.

Author: fubuloubu
Date: 2018-05-15T17:37:03.799Z

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.

Author: maraoz
Date: 2018-05-15T19:31:48.273Z

Count me in! 
Probably 2 or 3 Zeppeliners will be around in ETHBerlin and we’d love the be part of this conversation!

Author: boris
Date: 2018-05-15T20:11:20.877Z

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

Author: mariapaulafn
Date: 2018-05-15T21:43:20.459Z

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.

Author: TomLindeman
Date: 2018-05-15T22:25:53.959Z

Looks like EthBerlin is Sept 7-9 is that correct?

Author: maurelian
Date: 2018-05-15T23:12:16.201Z

Looks like EthBerlin is Sept 7-9 is that correct?

Yes.

Author: fubuloubu
Date: 2018-05-16T00:12:58.908Z

boris:

So – ask for volunteers. This might come from a company that has bandwidth of some people internally or an individual.


We volunteer as tribute!



 boris:

I am happy to help support a lead organizer in figuring out / iterating “how to run working groups”


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.



 boris:

pair programming


Have you ever tried mob programming?

Author: maurelian
Date: 2018-05-16T00:51:43.198Z

boris:

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.


I don’t think it’s quite working groups, but also definitely not just 1 to many presentations either.



 boris:

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


Right, and it might be the case that ConsenSys can marshall some resources to help with this. I will inquire.

Author: fubuloubu
Date: 2018-05-16T02:14:10.626Z

maurelian:

Right, and it might be the case that ConsenSys can marshall some resources to help with this. I will inquire.


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.

Author: maurelian
Date: 2018-05-16T02:28:00.134Z

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.

Author: fubuloubu
Date: 2018-05-16T02:47:34.699Z

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.

Author: fubuloubu
Date: 2018-05-16T02:48:40.655Z

maurelian:

But I also think this should have a fairly “For Us, By Us” feel, so input from a number of auditing firms is needed.


100% for us, by us (FUBU lol)
We need mass participation to be successful!

Author: fubuloubu
Date: 2018-05-16T02:57:37.917Z

maurelian:

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.


Potential topics:

Guidelines vs. “Best Practices” (Software Engg)
Audit documentation
Governance of guidelines
Event response (adding community knowledge)
The role of insurance as a protection mechanism
Envelope expansion of your application
Formal Verification tools
Coverage testing types
Coding documentation (natspec/radspec)
Requirements traceability
Ensuring Developer adoption
Peer review / community review
Game theoretical analysis (@mattdf)

auditing mechanism design

Author: mariapaulafn
Date: 2018-05-16T07:30:33.270Z

Indeed, feel free to propose any date around that period, and I can make it work with Full Node. How many people are you?

Author: mattdf
Date: 2018-05-16T10:36:19.499Z

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.

Author: ben-kaufman
Date: 2018-05-16T10:56:23.372Z

This event sounds like a great idea!
Would be happy to help if I can.
I think it would be great to talk about guidelines for writing tests for smart contracts.

Author: gakonst
Date: 2018-05-16T10:57:13.892Z

Count me in:)
I believe it would be really useful to onboard individuals of the infosec community who are not into Ethereum Security.
I’m also interested in discussions around the ethics/legal consequences of hacking a smart contract.

Author: izqui
Date: 2018-05-16T11:43:41.326Z

As the authors of a fairly complex system ourselves , some people from the Aragon team would love to attend.

Author: fubuloubu
Date: 2018-05-16T12:10:40.147Z

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.

Author: mattdf
Date: 2018-05-16T13:45:15.393Z

It’s not out of scope imo, certainly not wholly. If a contract is designed to prevent X, and it succeeds in preventing X, but you can make Y happen which is an automorphism to X in terms of its functional properties, then in effect you’ve failed at properly trying to prevent X. To me that’s still part of security, and doesn’t always have to involve simulations or data.
A trivial example would be a token contract that doesn’t allow transfers for N days, but that allows the loophole of contracts being able to buy tokens which can then issue trustless futures wrapper tokens that the owner can automatically redeem for the underlying “real” token once the token contract allow transfers.
From a code perspective, a simple “pause” on the transfer function would be correct, but would fail to actually prevent the effect of balance ownership changing hands.

Author: fubuloubu
Date: 2018-05-16T13:58:28.633Z

Ah, I was thinking from a slightly different perspective. Something like “this function requires staking >=1500 tokens, which will be enough to prevent fraud”. I can verify that the 1500 is the minimal allowed, that there is no way around it for a particular part of the program, but I cannot reasonably validate that “fraud” is prevented or that 1500 is enough tokens to stake.
You can only validate the behavior of the contract, my argument is that human behavioral response is “out of scope” of a software security audit. There is definitely overlap, and that goes into the logical analysis behind the goals and specification of the project, but I wouldn’t want to be on the hook for validation of the correctness of some mechanism actually working, only that it was properly implemented per the spec.

Author: mattdf
Date: 2018-05-16T14:03:12.093Z

Yes I agree you wouldn’t include economic security parameters in an audit for e.g. casper’s smart contract for example since that’s on a completely different level. There are overlaps though, like the one I described, which have to do with “what can other smart contracts do/achieve, if I write my smart contract this way” that aren’t just reentrancy. I think “what smart contracts can do” and “human behaviour response” are different, as the latter is unlimited, unlike the former.

Author: fubuloubu
Date: 2018-05-16T14:10:19.455Z

Awesome! Would love to hear a presentation of this at the event!

Author: maurelian
Date: 2018-05-16T14:12:25.439Z

I agree with limiting the scope to things contracts can do, and I can see how that might be called “Game theory/mechanism design”, but I think it’s also just “Implementing a system that adheres to the spec, given the capabilities of the underlying vm”.
My main concern is with keeping the event focused on narrow range of topics, to maximize the depth of insight and learning.

Author: fubuloubu
Date: 2018-05-16T14:41:13.079Z

maurelian:

keeping the event focused on narrow range of topics, to maximize the depth of insight and learning.


I would argue getting a survey of different topics would be the most insightful, so we can gain full appreciation for the range of problems and different solutions, and start to form consensus around what different responsibilities exist and how we ensure they get satisfied.
Most of us are experts in our fields, the value comes from cross-pollination.

Author: RexShinka
Date: 2018-05-16T18:07:06.228Z

Hi Rex here also from SecurEth.  I would like to volunteer in co-ordinating the mini un-conference.  I can maintain the wiki of topics,  I can help in co-ordinating the day and such.  Did you mention a magic button?

Author: fubuloubu
Date: 2018-05-16T18:26:26.621Z

How about we hold this unconf before the hackathon? And then try and secure a speaking slot during the conference and summarize what happened for everyone else? I’m thinking about the 5th
P.S. who likes the name “SmartCon” for this unconference?

Author: gakonst
Date: 2018-05-16T18:38:55.562Z

“EthSec (Con)” is too cliche you think?

Author: maurelian
Date: 2018-05-16T21:03:20.283Z

IMO a ‘Con’ is a large event. Preference for ‘Camp’.

Author: makoto
Date: 2018-05-17T05:20:03.712Z

Hi, Makoto from partly ENS, partly BlockParty, and occasionally security auditing. Love to participate & help if it’s pre ETHBerlin event. If you guys are also considering different location, London is not a bad location either. I am currently planning to organise something similar for ENS and so gathering some knowledge about logistics/venues, etc.
One question is, is this going to be free event or paid event? If free event, we could try my BlockParty event registration dapp (then you guys can try to crack it and share different approach during the event) .

Author: drgoldberg
Date: 2018-05-17T06:54:00.388Z

David from BlocTrax. I’m in. Here’s a blog post my co-founder and I wrote about our philosophy of a smart contract security audit. Hope you find our perspective interesting and would love to contribute to the community goals outlined above. https://medium.com/@bloctrax/philosophy-of-a-smart-contract-security-audit-1e111efd28cb

Author: hughkarp
Date: 2018-05-17T07:54:43.972Z

Hi, Hugh from Nexus Mutual. We’d love to participate and can hopefully provide some views/opinions on using insurance as a second layer safety net, after you’ve done all your audits etc
We don’t have much capacity to help with hands on coordination but we can help with a small amount of funding if you consider it appropriate (definitely don’t want to mess with the For Us, By Us feel). Let me know.

Author: RexShinka
Date: 2018-05-17T12:48:24.729Z

I am co-coordinating with @jpitts to get a meeting wiki started and I am making a summary doc that will help us coalesce on agenda, venue, date etc.  Great energy here.

Author: fubuloubu
Date: 2018-05-17T13:36:04.396Z

Hi Hugh, would LOVE to have you in attendance and give a talk about insurance as a safety net against bugs and subsequent losses. You can audit out 99% of known bugs, but there is still human error at play, and the unknown future state of insecure patterns. I was chatting with someone about insurance solutions for smart contracts, and I think the biggest discussion points are “who makes decisions on event classification?” and “how would the funds even be used?”. I think there are actually some opportunities here to create alternative business models for auditing firms, both in event response contracts and bug prediction markets. Would be a super facinating perspective to hear from!
We would definitely appreciate some funding for the event. We’ll try to lock up some logistics in order to estimate costs, but we definitely want this to remain a free event for all to participate in, so sponsorships will be important!

Author: fubuloubu
Date: 2018-05-17T13:42:10.822Z

makoto:

Hi, Makoto from partly ENS, partly BlockParty, and occasionally security auditing. Love to participate & help if it’s pre ETHBerlin event.


Hi Makato, would love to have you! We are definitely thinking about it being at ETH Berlin, would like to do it prior to the event (maybe Sept 5th or 6th?) so we can get good attendance at the event as many people would attend.
I would also like to do it before so we can get a time slot in the ETH Berlin talks and summarize what happened as well as the highlights so more people can know about the event and our collective efforts to organize the smart contract security space.

Author: hughkarp
Date: 2018-05-17T14:35:12.576Z

Great! We definitely see insurance as a supplement to auditing and I can ramble on for a while on those topics, so hopefully you all find it useful 
Very briefly, our model effectively decentralises the claims decision making process and the model also offers a supplement to the auditing model where you can earn funds on contracts you deem secure (like underwriting). If you want to dive deeper you can check out our website
Really looking forward to it and do let me know on sponsorship.

Author: boris
Date: 2018-05-17T14:53:08.696Z

Here’s the example of the agenda that @jpitts did Proposed agenda for the “Council of Berlin”, set for July 14-15
We’re doing this for the first time too, so great to have another working group getting started at the same time.

Author: NickErrant
Date: 2018-05-17T17:32:33.899Z

Hi all, I’m Nick from https://solidified.io, we would be happy to contribute talks/content and help with logistics/sponsorship!
Personally, would really like to see discussion on tools that improve the manual auditing process (e.g. lower the cost of context switching when reading contracts with unwieldy levels of inheritance). Also think we should have a conversation about who we, as auditors, are ultimately accountable to. Nominally it’s the clients, but I believe there’s a higher responsibility to the users of a smart contract I’ve audited. I’d like to hammer out what that means in practice.

Author: lsaether
Date: 2018-05-18T06:46:38.878Z

Hi, Logan from ChronoLogic, we’re working on decentralized scheduling of transactions on Ethereum. We rebooted the Ethereum Alarm Clock project and are working on a next-gen version called Chronos. We architect with smart contracts so we know first hand the importance of eliminating bugs from code. It’s maybe a bit askew to the topic, but we can bring some insights about how to make security tradeoffs between on-chain and off-chain and how to use economic incentives to secure a protocol, since this is what we’re working on currently with the transaction claiming mechanism.
Would love to attend!

Author: fubuloubu
Date: 2018-05-18T12:58:38.500Z

It would definitely be interesting to hear about the development experience of a few developers of complex applications. We may not want to dive too deep into cryptoeconomic security mechanisms, but would totally be interested in hearing about on-chain vs. off-chain security and the different problems you face with both.

Author: arashxo
Date: 2018-05-19T16:32:00.530Z

Arash from New Alchemy here. My team and I can definitely contribute to this event. Similar to others, can’t provide much organizational/logistics help, but happy to engage in developing the agenda and discussion topics.
I would also be interested in discussing security of standard frameworks that exist out there, cryptographic assessment and game theory analysis as well as key management.

Author: fubuloubu
Date: 2018-05-20T03:57:30.142Z

arashxo:

cryptographic assessment and game theory analysis


I’d like to propose we leave cryptoeconomic assessment mostly out of the discussion. It does play a role in the overall security discussion, but analysis of economic mechanisms outside of driving security is out of scope in my opinion.

Author: chapati
Date: 2018-05-20T14:17:47.535Z

Hey 
Philip from Brickblock here. We’re currently undergoing an audit of a relatively complex smart contract system.
We’d be happy to pitch in some resources, be it financial or other. Let me know what we can do to help.

Author: RexShinka
Date: 2018-05-20T18:21:22.017Z

Excellent, we need developer participation also so this is awesome.  As for assistance we will know more in the coming weeks as we put things together.  Looking forward to seeing you.  We will be in touch

Author: fubuloubu
Date: 2018-05-21T05:31:22.596Z

Proposed gathering of the Security community Working Groups


    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 e…
  

@mariapaulafn I was hoping that we could present a summary of this event to those in attendance at ETH Berlin at a talk given during the event. There is a lot of interest to attend, but we would like to focus this event for more invested individuals and teams. I think giving a presentation would allow others to learn about what we discovered after we’ve had a chance to digest our findings for the wider community.
We would then suggest that those who do not currently work full-time either on smart contract development or as smart contract auditors consider attending that session so we can save more space for these parties and create a high level of discussion. I hate to suggest exclusivity, but I think the right audience for this gathering is critical to it’s success.
What do you all think?

Author: mariapaulafn
Date: 2018-05-21T06:23:35.403Z

fubuloubu:

resent a summary of this event to those in attendance at ETH Berlin at a talk given during the event. There is a lot of interest to attend, but we would like to focus this event for more invested individuals and teams. I think g


Hi, we are taking speaker submissions at the moment for ETHBerlin, this event is something separate of course.
Who you decide to invite is up to you, I am just facilitating resources and organization. I am a big fan of inclusion, hence never a supporter of exclusivity, but I will not put any restrictions as I respect your POV.

Author: grosu
Date: 2018-05-21T11:15:14.290Z

:Grigore from Runtime Verification (RV) here.  We would also like to participate in this event.  We do formal verification of smart contracts; see our approach here: https://runtimeverification.com/smartcontract/.  This is also the approach we are following to verify Casper, as part of this grant: https://blog.ethereum.org/2018/03/07/announcing-beneficiaries-ethereum-foundation-grants/.  We can give a presentation about formal verification in general and about our approach in particular.

Author: RexShinka
Date: 2018-05-21T16:13:32.015Z

All,  it is imperative we choose a date ASAP so we can reserve the venue which may be available at very low cost!!  I was thinking Thursday 6 Sept, the day before EthBerlin.  Someone mentioned 5 Sept also.  Comments?

Author: boris
Date: 2018-05-21T16:57:33.468Z

The learning from previously is — pick a date, everyone will then attend or not

Author: RexShinka
Date: 2018-05-21T22:36:28.307Z

Then this event will take place on Sept 6.  I will now 100% the Full Node space.

Author: RexShinka
Date: 2018-05-21T23:02:25.550Z

Grigore - you are 100% on topic and that would be great to hear about!  This would be very helpful.  Looking forward to seeing you.

Author: fubuloubu
Date: 2018-05-22T01:23:17.662Z

@mariapaulafn are we a go for using Full Node on Thursday Sept 6th from 0800-1800?
What is the AV situation there?

Author: mariapaulafn
Date: 2018-05-22T06:33:02.787Z

Yesterday was a holiday in Germany so I sent the email request. I had pitched it before and they liked the idea.
No worries about AV both rooms will be fully stocked with new equipment, the build finishes in 2 weeks. They are really bringing in the best equipment.

Author: fubuloubu
Date: 2018-05-22T11:48:28.611Z

Awesome! Do we need any people to operate the equipment? I would like to video it like we did with the UXunconf, that was very handy to refer others to and for myself to look at what happened or what I missed.

Author: PhABC
Date: 2018-05-22T13:39:16.087Z

It’s been mentioned a few times already, but to put more emphasis, I would prefer if discussions were favored instead of presentations, or at least on par. For example, 15 minutes presentation with 15 minutes Q&A / discussion.

Author: rmi7
Date: 2018-05-22T21:34:34.375Z

Hi, Alexander Remie, solidity developer from dether.io here. Been seriously interested in smart contract security ever since I rolled into the blockchain space. Done some smart contract security reviews and created 2 open-source npm modules (solhydra + soljitsu) to ease some of the smart-contract-reviewing-pains 
I will attend

Author: RexShinka
Date: 2018-05-22T21:51:54.350Z

Phillipe, I have changed format 2 where we can have 8-10 presentations with more time for discussion.  We have 8 hours of active time.  At 30 minutes per pres and discussion we can have 16, at 45 minutes we can have 10.  Lets get some more comments to firm things up

Author: fubuloubu
Date: 2018-05-23T03:14:47.480Z

Those are fantastic tools! Thanks for creating them!
Looking forward to seeing you at the event!

Author: joey
Date: 2018-05-23T07:41:15.355Z

Is that the proof of time project?
For me personally, really interested in the cross between zk and smart contracts (stuff Christian from truebit worked on a while ago), also truebit

Author: fubuloubu
Date: 2018-05-23T11:46:04.471Z

I am as well. One of my projects is aiming to use zkSNARKs to handle transactions of a sensitive token.
However this conference will not focus on software design ideas, only how we ensure developers write secure smart contract code.

Author: maurelian
Date: 2018-06-01T12:36:24.925Z

Wiki and more organization happening here:




Wiki: Gathering of Security Community Happenings


    Date
Thursday September 6, 2018 
NOTE: Day before ETH Berlin 
Venue
Full Node 
Host: @mariapaulafn (Golem/ organizing ETHBerlin ) 
Facilitators: @fubuloubu @RexShinka @rpavlovs @captnseagraves (SecurEth Foundation) 
Schedule and Format


Attendees
At capacity for event: 110 attendees 

Further Discussion
 
 
https://discourse.secureth.org/t/eth-berlin-unconference-workshop-topics/45/18
https://discourse.secureth.org/t/eth-berlin-unconference-lightning-talks/20/37

Author: yondon
Date: 2018-06-01T22:35:08.095Z

Hi all! My name is Yondon and I work on smart contract dev at Livepeer. We just deployed the first version of our smart contract system to mainnet a few weeks ago (https://github.com/livepeer/protocol) with plans to make improvements over time.
In addition to the topics already mentioned by others in this thread, I’m also interested in discussing how security requirements and audit processes can be scoped to take into account the stage of a system. For example, what mental framework do others use to determine the minimum level of security required to deploy an alpha version of the system in order to start testing certain assumptions about human behavior (given that a lot of the contracts that developers deploy will be mechanisms that assume some behavior in response to the rules of mechanisms that will not be observed in practice until they are live) knowing that the system will be upgraded potentially often in the future? Given that this is likely going to become a more common case in the future, can we transform the relationship with security auditors such that they become on-going partners as opposed to providers of one time stamp of approvals? These questions are motivated by a broader question which is what are the best practices that can enable smart contract developers to get some of the benefits of iterative development while still upholding a high level of security?
Definitely interested in attending this gathering and happy to contribute talks/content wherever appropriate!

Author: fubuloubu
Date: 2018-06-02T03:29:29.975Z

yondon:

I’m also interested in discussing how security requirements and audit processes can be scoped to take into account the stage of a system.


This is a great point of conversation about expectations!



 yondon:

[W]hat mental framework do others use to determine the minimum level of security required to deploy an alpha version of the system in order to start testing certain assumptions about human behavior[…] knowing that the system will be upgraded potentially often in the future?


For me, I believe you should be testing out those mechanisms as well as you can through simulations, user behavior studies, and testnet trial periods (backed by real ETH, if incentivization is desired) before putting that code on the mainnet. You could do this before or during a security audit.
Upon a successful audit, you can move this alpha test to the mainnet, where you should gradually increase your risk as you gain confidence in the proper operation of your contracts. You can achieve this through “envelope expansion” that you personally shoulder the risk for. This means that the amount of valuable assets you handle through your framework should be limited in some way to this comfort level based on a risk assessment, and only increased as you feel comfortable with it’s proper operation. It should only grow beyond your personal capability to shoulder the risk when you have achieved that level of comfort in it’s proper design throughout the range of capabilities you’ve designed for. I call this the “public bug bounty” portion of your contract system (isn’t this what all smart contracts are right now?).
This is where I think insurance would be handy, as a means for shouldering that risk and providing an assurance that you are capable of repaying your users in case an unintended event occurs. Over time, insurance will naturally limit the envelope as I was describing.
Upgradability should not be a shortcut for this process, you still have to do the majority of your effectiveness and design considerations up front, with upgrading your contract to be considered only in a normal improvement cycle if a vulnerability is found later or new functionality is to be added. You should have a plan of action for this, how often you will check for new vulnerabilities and how you will handle them if discovered. Auditing should definitely be a part of this upgrade process as well, with new features receiving a full audit. (small changes should at least be peer reviewed, and vulnerability patches should receive enhanced attention)
We should get much more into this and discuss what a maintenance/support plan looks like. This might include something like instructions for white hats who discover vulnerabilities (and maybe even a continuous bounty program for privately communicating vulnerabilities). These should also be disclosed to the wider group of developers and auditors for assessment of existing contracts.



 yondon:

Given that this is likely going to become a more common case in the future, can we transform the relationship with security auditors such that they become on-going partners as opposed to providers of one time stamp of approvals?


I definitely think this is worth discussing further. The concerns here are that there must be a sufficient separation between the auditor and the developer or the relationship will not be effective. There is nuance here that we can work between, but one thing I’ve mentioned previously is checkpoint events along the development cycle, where auditors are invited to review plans for implementations before going too far in the design process, to avoid making costly mistakes early on in the design process. This is similar to the waterfall or V model of S/W Engg, which (unlike agile) focus on getting things right earlier before expensive layers of testing and audit happen (which mitigate even more expensive “events”).



 yondon:

These questions are motivated by a broader question which is what are the best practices that can enable smart contract developers to get some of the benefits of iterative development while still upholding a high level of security?


I think this is one of the main questions we want to answer at our gathering: how do we ensure more consistent and robust security?

Author: makoto
Date: 2018-06-02T15:17:34.251Z

Hello. What do I need to do to get my name listed on the participant list?

Author: RexShinka
Date: 2018-06-02T22:35:13.489Z

Your name will be added.  Welcome. Do you have specific interests?

Author: yondon
Date: 2018-06-04T14:33:37.017Z

Upon a successful audit, you can move this alpha test to the mainnet, where you should gradually increase your risk as you gain confidence in the proper operation of your contracts. You can achieve this through “envelope expansion” that you personally shoulder the risk for. This means that the amount of valuable assets you handle through your framework should be limited in some way to this comfort level based on a risk assessment, and only increased as you feel comfortable with it’s proper operation.

I definitely agree that leveraging simulations, user behavior studies and testnet trial periods are crucial before hitting an alpha release on mainnet. I’m curious what you imagine envelope expansion would look like in practice or if you have any examples of well executed expansion processes in mind.

Upgradability should not be a shortcut for this process, you still have to do the majority of your effectiveness and design considerations up front, with upgrading your contract to be considered only in a normal improvement cycle if a vulnerability is found later or new functionality is to be added.

I agree that upgradable contracts should not encourage developers to skip over executing a thorough design process before implementation/deployment. Although, I do think centralized upgrade mechanisms could also be another way to naturally limit envelopes. During an alpha, centralized upgrade mechanisms enable more efficient bug fixes and improvements, but at the same time also drastically change the trust model of the system. As a result, perhaps users would be more hesitant to allow the system to handle as many assets early on. This is like a “training wheels” mode for the system during an alpha (this is what we are currently doing for Livepeer) and once the system reaches a more mature stage, the upgrade mechanism might be executed via a more decentralized process.

This is similar to the waterfall or V model of S/W Engg, which (unlike agile) focus on getting things right earlier before expensive layers of testing and audit happen (which mitigate even more expensive “events”).

While this model has the nice property of avoiding expensive “events”, I do also see the downside in executing on expensive layers of testing and auditing up front only to realize that certain assumptions were wrong and that the deployed mechanism, while logically correct, does not achieve something valuable or meaningful.
Although the agile model of development might not work for smart contract development given that it represents a much different paradigm than other forms of software engineering, I’d be interested to see if we as a community can nonetheless borrow some of those ideas around validation of assumptions and combine them with the more robust security practices that might be found in the waterfall model of development. Perhaps the idea of checkpoint events you mentioned could be a starting point.

Author: fubuloubu
Date: 2018-06-04T19:55:04.097Z

I think of upgradability in the same vein as governance:



 yondon:

once the system reaches a more mature stage, the upgrade mechanism might be executed via a more decentralized process.


This could be a migration over to DAO control of the upgrade process through user voting. The developer would be an important signal in this vote, but ultimately control is left to participants.




 yondon:

I’m curious what you imagine envelope expansion would look like in practice or if you have any examples of well executed expansion processes in mind.


The idea is to limit risk at each stage of experimentation. What is the specific goal of each stage, how is it successful, what future stage does it enable? How can I prove this in the least risky and most useful way possible to prove my goals? How much actual money needs to be in this system to be proven successful? Similar to:



 yondon:

I do also see the downside in executing on expensive layers of testing and auditing up front only to realize that certain assumptions were wrong and that the deployed mechanism, while logically correct, does not achieve something valuable or meaningful.


A point I would make with this is that there should be a more structured way of identifying whether the mechanism will work with much smaller stakes (i.e. before an audit or on a smaller codebase). It also goes into the upgrade process as you work on your platform and determine the mechanism at play is not sufficient to achieve the goals that are set. I think my ultimate point is to have a better plan up front for validation of assumptions in smaller steps than the full-on application dealing with the largest amounts of value. You are hinting at this as well in this quote:



 yondon:

I’d be interested to see if we as a community can nonetheless borrow some of those ideas around validation of assumptions and combine them with more robust security practices…


This is very much the right tradeoffs to be considering, in my opinion. How do I create a plan of action that is flexible enough to respond to changing conditions as I learn more about my application, yet robust enough to respond effectively to those very same changing conditions under the unique demands of the Ethereum network?

The reason why I’m asking more questions is that I think the answer is unique to each different application. The real answer, in my opinion, is better planning and documentation so we can do a better job communicating with others of our own intent so we can get excellent feedback from the largest possible amount of knowledgeable people to be successful.
And also be extremely clear about how much money actually needs to be on the line to prove success, otherwise it will be more money than you anticipate, more so than your risk model will support.

Author: yondon
Date: 2018-06-04T20:39:12.850Z

The idea is to limit risk at each stage of experimentation. What is the specific goal of each stage, how is it successful, what future stage does it enable? How can I prove this in the least risky and most useful way possible to prove my goals? How much actual money needs to be in this system to be proven successful?

Agree that these are all crucial questions to ask. In my opinion, more concrete examples of what this type of envelope expansion looks like in practice with specific applications would also be helpful reference educational material for developers. As you mentioned, the right process will likely look different from case to case, but just having a set of reference points that demonstrate what secure staged experimentation for applications might look like could teach people a lot even if the approach you choose to take ends up differing a lot in the end. Perhaps one of the short presentations at this gathering could be focused on trying to walk through the design of these stages for one or more examples with the subsequent discussion focused on extracting key techniques and common themes?

Author: fubuloubu
Date: 2018-06-04T21:04:03.822Z

That is a great suggestion.
@RexShinka, @rpavlovs, and I are working on Development guidelines next week with SecurEth. We intend on developing a structured walk through very similar to what you have described as a good example of what a process looks like as a learning experience. We will definitely be presenting and asking for community feedback on these guidelines at the September event, so it is good to hear this sentiment echoed.
Common themes and key techniques is something we need to discuss during the event and codify for our community in an extremely accessible way.

Author: johba
Date: 2018-06-29T08:11:38.347Z

Hi guys,
i’m Johann from parseclabs.org. We are working on Plasma chains for gaming. I’m doing research into limitations of smart contracts execution on Plasma and would love to share my findings in terms of security and safety implications at the event.

Author: fubuloubu
Date: 2018-06-29T21:30:22.335Z

Personally would be very interested in that! Working on several Plasma variations and interested in the general case of smart contract execution.
If smart contracts can be executed similarly on the plasma chain as on the main chain (e.g. without any explicit tie except the native tokens linked to the plasma token), would that allow something useful enough to a subset of the network to allow more use-cases?

Author: johba
Date: 2018-07-02T10:20:07.268Z

would that allow something useful enough to a subset of the network to allow more use-cases?

The simplest set of use-cases I see are Satoshi-dice like applications that do conditional routing of funds, or group and funnel payments, without taking custody.
Our interest at Parsec Labs is to enable games where funds can be held in custody, and the fair execution of game rules can be verified on chain.
The holy grail would be to allow more Plasma bridges that validate sub-chain, as described in the original Plasma paper.
Until now I can say the the latter 2 are probably not possible without additional constructions like a PoS set of notaries, or similar, due to the data availability problem.

Author: drgoldberg
Date: 2018-07-06T04:44:44.733Z

Hi David from bloctrax here. Would love to join as a participant for the event. Wrote this blog post about our philosophy of a smart contract security audit in case anyone is interested and hasn’t seen it yet. https://medium.com/@bloctrax/philosophy-of-a-smart-contract-security-audit-1e111efd28cb

Author: pmackay1982
Date: 2018-07-06T15:47:00.150Z

Good Morning -
Patrick MacKay from Runtime Verification, Inc.  We provide formal verification - protocol verification and code verification - of smart contracts.  Our founder and CEO, @grosu, already expressed our interest in attending the event.  I’d like to confirm my intention to attend.  I look forward to seeing everyone in early September.  Do we have any specifics on date and venue as I’d like to book my travel.  Thanks in advance for your help. - Patrick

Author: fubuloubu
Date: 2018-07-06T15:50:28.352Z

Hey Patrick, see this post for the venue and other information. It is confirmed.
https://ethereum-magicians.org/t/wiki-gathering-of-security-community
Still working on schedule

Author: fubuloubu
Date: 2018-07-12T23:41:02.059Z

We have created a Smart Contract Security focused discourse to talk further about related topics.
Please direct all further conversation of this topic (the security Unconf before ETH Berlin) to this thread in the SecurEth discourse: https://discourse.secureth.org/t/ethberlin-security-unconference-agenda-post-topic-here/
More general discussions of security topics should be directed to the overall discourse as well.

Author: cdili
Date: 2018-07-20T18:37:59.452Z

Humbly suggest that the community doesn’t need yet another discourse.  Security is important and there’s no need to create another discourse with a different set of administrators.  Thanks