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