4 ms·

I think the big reason this happens is because smart contracts are immutable at the lowlevel. Once it's declared, it's done. I think this is very good for audi

by ryebit 6y ago

I think the big reason this happens is because smart contracts are immutable at the lowlevel. Once it's declared, it's done. I think this is very good for auditability and security. But yeah, that quote is dead on. It's not quite as hot at a higher level, because things go wrong (bugs, malfeasance, mistakes, etc). I think the current lowlevel framework is fine, because it's allowing different projects to explore how to introduce flexibility back into the system at a higher level -- but because it's being done at the level of a project within the Ethereum ecosystem, each approach can live & die on it's own, without risking the entire ecosystem on one approach. The main set of coding patterns I've seen all center around deploying contracts which act as an "upgradable proxy" -- an immutable frontend contract, which can be redirected to point to another contract that does the actual work. This "redirect" usually can only be done via txn signed by an "admin" account, which may be a single anon -- or it may be something more complex, like MakerDAO or Aave.com, where any updates are proposed by the dev team, but have to be approved by on-chain governance votes. Said votes in turn literally have $$$ staked on-chain to properly motivate them to make things work. There are also time-locks on many of these updates, giving users a last chance to run for the hills if governance does something malicious / stupid. The nice thing about that structure is that it also allows governance to let in updates which compensate users for mistakes or exploits at a meta-level, all without violating the underlying immutability of the smart contract bytecode. --- It's a pretty rapidly evolving space, and I'm sure what I described won't resemble the final form in even a few years. I think it's really great to see that there is a way to introduce justice and flexibility on top of an immutable system, rather than making the system itself become mutable. This allows the immutability of the lowlevel system to act as a source of trust between anonymous groups, that they have to act within some immutable set of ground rules, while then re-introducing the flexbility on top, so humans can act like humans when mistakes occur.

aabhay 6y ago
All things considered, is this truly less complicated than a hand written handshake contract? The real solution is risk mitigation through deposits and payment plans. Put another way: how good is a smart contract if it’s easy to create a deceptive one?
- ryebit 6y ago
  From a technical perspective, yeah, I'd say it's a bit more complicated. But establishing agreement with another human means I have to establish a common language with them, then work out what we're agreeing to, then establish some set of mutual trust between us (usually involving some form of identity verification, even if it's a "who are you on twitter?" level of thing). And then we perpetually have to track that the other person's incentives haven't changed outside of the contract in such a way that violating it would be more profitable. The effort involved in all of that scales very poorly, especially from the service provider's perspective. On the other hand, if someone wishes to operate in good faith, their incentive is to make the smart contract as simple as possible, and as amenable to independent verification from outside parties (as well as theorem provers). And no one has to worry about establishing mutual trust with the other person, or that they'll just change their mind in the future. Even if a contract is upgradable, if you only choose to work with ones that are either immutable, or require a timelock / voting period before changes take effect, you (collectively all the consumers of the contract) know your margin of safety. And that margin of safety is provided because you can trust the base layer is itself immutable and secured. Whereas with risk mitigation through bonds etc, who is the trusted third party we mutually agree to hold our deposits? how do each of us trust that third party isn't in league with one of us? (I trust the "Certified Bank of Nigeria In England", but do you?). That's the core bit that a smart contract platform like Ethereum provides -- a base layer for establishing mutual trust in objective terms. You can build whatever manner of agreements on top of such a base layer, but if the base layer isn't there, each separate agreement (expensively) requires the two parties find some common ground.
  - ryebit 6y ago
    followup - shout out to https://defisafety.com/ https://defisafety.com/, which is attempting to curate lists of projects with publically performed audits, to make it easier to assess quality of their code (and how closely code adheres to human statements). it's nascent, but IMO a good step forward.

by ryebit 6y ago

aabhay 6y ago

All things considered, is this truly less complicated than a hand written handshake contract? The real solution is risk mitigation through deposits and payment plans. Put another way: how good is a smart contract if it’s easy to create a deceptive one?

ryebit 6y ago
From a technical perspective, yeah, I'd say it's a bit more complicated. But establishing agreement with another human means I have to establish a common language with them, then work out what we're agreeing to, then establish some set of mutual trust between us (usually involving some form of identity verification, even if it's a "who are you on twitter?" level of thing). And then we perpetually have to track that the other person's incentives haven't changed outside of the contract in such a way that violating it would be more profitable. The effort involved in all of that scales very poorly, especially from the service provider's perspective. On the other hand, if someone wishes to operate in good faith, their incentive is to make the smart contract as simple as possible, and as amenable to independent verification from outside parties (as well as theorem provers). And no one has to worry about establishing mutual trust with the other person, or that they'll just change their mind in the future. Even if a contract is upgradable, if you only choose to work with ones that are either immutable, or require a timelock / voting period before changes take effect, you (collectively all the consumers of the contract) know your margin of safety. And that margin of safety is provided because you can trust the base layer is itself immutable and secured. Whereas with risk mitigation through bonds etc, who is the trusted third party we mutually agree to hold our deposits? how do each of us trust that third party isn't in league with one of us? (I trust the "Certified Bank of Nigeria In England", but do you?). That's the core bit that a smart contract platform like Ethereum provides -- a base layer for establishing mutual trust in objective terms. You can build whatever manner of agreements on top of such a base layer, but if the base layer isn't there, each separate agreement (expensively) requires the two parties find some common ground.
- ryebit 6y ago
  followup - shout out to https://defisafety.com/ https://defisafety.com/, which is attempting to curate lists of projects with publically performed audits, to make it easier to assess quality of their code (and how closely code adheres to human statements). it's nascent, but IMO a good step forward.