41–50 of 319 posts
Hi all — I wrote these notes with my colleagues at PSL while trying to wrap our heads around the madness that is Web3/Crypto. I’m an engineer by background and sort of a skeptic by nature; I think of this piece as a collection of loosely connected, hopefully pragmatic opinions from a builder’s perspective.
> Protocols like SMTP (1981; email), TCP (1983; reliable packet transmission), HTTP (1991; web), and XMPP (1999; chat) all created immense value while capturing little for their inventors. Blockchains upend this, allowing inventors to capture considerable value for themselves. That... seems like a huge negative to me. No wonder crypto enthusiasts give me the same feeling as relentless door-to-door salesmen.
Also, the page requires JS to render, so it's probably crap anyway.
> Protocols like SMTP (1981; email), TCP (1983; reliable packet transmission), HTTP (1991; web), and XMPP (1999; chat) all created immense value while capturing little for their inventors. Blockchains upend this, allowing inventors to capture considerable value for themselves. That... seems like a huge negative to me. No wonder crypto enthusiasts give me the same feeling as relentless door-to-door salesmen.
The fat protocol hypothesis hasn't been proven. If your app has value, why would you let a protocol take any of it?
> The network effects behind TCP/IP's and Linux's success are fairly clear and reduce ultimately to issues of trust and symmetry -- potential parties to a shared infrastructure can rationally trust it more if they can see how it works all the way down, and will prefer an infrastructure in which all parties have symmetrical rights to one in which a single party is in a privileged position to extract rents or exert control.
Sure you may be able to build a bespoke proprietary protocol on top of the open foundations of http or the bitcoin and etheream blockchains, but businesses will have an incentive to shop for more open systems if they are staking anything important on it.
http://www.catb.org/esr/writings/magic-cauldron/magic-cauldr...
Earlier quoted context omitted.
So you deploy a new contract and tell users why they should update. Then they can choose to use the new version or not. I don't think you really understand this idea.
What you’re describing does indeed happen — and in many cases I think it’s a good approach — but it’s not the same as what I’m talking about. You might find these two blog posts useful: 1. OpenZeppelin’s post on the Ethereum proxy pattern: https://blog.openzeppelin.com/proxy-patterns/ 2. USDC’s adventure in upgrading their contract: https://blog.coinbase.com/usdc-v2-upgrading-a-multi-billion-...
Earlier quoted context omitted.
Original author here. I strongly disagree. While it’s certainly true that firmware on many devices can’t be or simply isn’t updated, it’s also the case that bugs ship. Because of this, engineers design and ship their more complex devices with the facility to upgrade firmware. Even my ages old stereo receiver is upgradable (although painfully so). But this is about smart contracts: code that in many cases moves money.…
Most (any?) smart contract platforms can theoretically bake in a concept of proxy upgrading or even decentralized governance over triggering the proxy into an upgraded contract. Sure it's complex now, but this is still very very new tech and those problems can easily be built upon and abstracted away.
> At the same time, smart contracts have some deeply problematic constraints: > Smart contracts can’t be upgraded. Smart contracts are deployed once and run forever; their code cannot be changed. The software development industry has literally zero experience with such a deployment model. I stopped reading here. First, this is factually wrong -- the software industry has tons of experience dealing with software that…
Original author here. I strongly disagree. While it’s certainly true that firmware on many devices can’t be or simply isn’t updated, it’s also the case that bugs ship. Because of this, engineers design and ship their more complex devices with the facility to upgrade firmware. Even my ages old stereo receiver is upgradable (although painfully so). But this is about smart contracts: code that in many cases moves money.…
By whom?
"Upgrading" a contract should require the approval of all parties to the contract.
> At the same time, smart contracts have some deeply problematic constraints: > Smart contracts can’t be upgraded. Smart contracts are deployed once and run forever; their code cannot be changed. The software development industry has literally zero experience with such a deployment model. I stopped reading here. First, this is factually wrong -- the software industry has tons of experience dealing with software that…
Original author here. I strongly disagree. While it’s certainly true that firmware on many devices can’t be or simply isn’t updated, it’s also the case that bugs ship. Because of this, engineers design and ship their more complex devices with the facility to upgrade firmware. Even my ages old stereo receiver is upgradable (although painfully so). But this is about smart contracts: code that in many cases moves money.…
First, if you're saying that you need a way to upgrade your money-managing code periodically because you will likely ship versions of it with show-stopping bugs (such as those that enable the destruction or theft of the users' funds), then why should I trust that you will ship flawless code for upgrades?
Second, if the combined security budget of the people who can carry out the upgrade is less than that of the majority of the block producers on the chain, then why build an upgrade procedure at all? Why risk it? Instead, just deploy a new version of the smart contract, and ask users to use that one instead. If it gets confirmed, then an honest majority of block producers will ensure that it stays confirmed. This takes no code at all. You simply sign the new code with the same key that deployed the old code to demonstrate that it originates from the same author(s). Let users decide on their own whether or not to use your upgraded code -- after all, it might introduce new bugs, and the "bugs" you are fixing might be features to other people. It's not your place to tell users what version of the code should be used, and what should not be used.
> Protocols like SMTP (1981; email), TCP (1983; reliable packet transmission), HTTP (1991; web), and XMPP (1999; chat) all created immense value while capturing little for their inventors. Blockchains upend this, allowing inventors to capture considerable value for themselves. That... seems like a huge negative to me. No wonder crypto enthusiasts give me the same feeling as relentless door-to-door salesmen.
Not everything is about capturing value and extracting profit. There had been something like hacker culture back then, Mr. Serious Business Ventures on HACKER News. Also, the page requires JS to render, so it's probably crap anyway.
Earlier quoted context omitted.
Original author here. I strongly disagree. While it’s certainly true that firmware on many devices can’t be or simply isn’t updated, it’s also the case that bugs ship. Because of this, engineers design and ship their more complex devices with the facility to upgrade firmware. Even my ages old stereo receiver is upgradable (although painfully so). But this is about smart contracts: code that in many cases moves money.…
> I’d put that in the category of code that really could benefit from carefully controlled upgradability. First, if you're saying that you need a way to upgrade your money-managing code periodically because you will likely ship versions of it with show-stopping bugs (such as those that enable the destruction or theft of the users' funds), then why should I trust that you will ship flawless code for upgrades? Second,…
You shouldn’t, because no code of sufficient complexity is flawless.
> just deploy a new version of the smart contract
On the Ethereum blockchain (for instance) storage and smart contracts are tightly coupled. If you move to a new smart contract you may well lose your state. This is fine in many cases and preferable in some. But not in others!