> 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.
An engineer's observations on Web3 and its possibilities
61–70 of 319 posts
Re: An engineer's observations on Web3 and its possibilities
#62> 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.
So crypto is doing the same for value/money. It's freeing it from the institutions (banks, governments, etc.) and allowing it to flow more freely and efficiently. This is why some people call it the internet of value/money. So, if you believe that freedom allows innovation to flourish, you should see this as a very powerful thing that could eventually be the backend of the entire financial system, just as TCP and other protocols are the backbone of the internet. It allows innovation to flourish at the edges, because we have stable monetary protocols that are open to anyone. A hacker in their basement can now build financial applications, or a group can coordinate in new ways through DAOs, or someone can just store value that isn't tied to any government.
Re: An engineer's observations on Web3 and its possibilities
#63Earlier 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,…
I can't see how the operation you describe here is defined or possible for any blockchain that hosts more than one smart contract. Just for a start, how do you decide whether to include a smart contract upgrade that the majority of verifiers doesn't care about either way (surely the most common case)? It's like saying that legislation doesn't matter because we have elections. The elections (consensus) produce the legislation (allowed transactions). You can squish those two layers together, but starts to break the premises of the underlying system (e.g. DAO fork).
I would love to know what software system you were thinking of when you wrote this. Or were you? Sincere question.
Re: An engineer's observations on Web3 and its possibilities
#64Earlier quoted context omitted.
> why should I trust that you will ship flawless code 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!
> You shouldn’t, because no code of sufficient complexity is flawless. So why build an upgrade procedure at all, when you don't have to? > On the Ethereum blockchain (for instance) storage and smart contracts are tightly coupled. Sounds like an unforced error on these smart contracts' authors parts, and should not be used as an excuse to compromise the principle of code immutability. If the possibility existed that t…
Flaws, once known, can be remediated. I don’t think macOS has bulletproof security but I’m sure glad Apple keeps updating it.
> In the Stacks blockchain (which I work on), we go one step further by making it so you can run an arbitrary read-only code snippet on the state of the blockchain at any point in the past (as given by a block hash).
That’s a super interesting design point; I’m excited to see where that leads.
Out of curiosity, how does this typically get exposed in dApps (or wallet UIs) built on Stacks?
Re: An engineer's observations on Web3 and its possibilities
#65Re: An engineer's observations on Web3 and its possibilities
#66Earlier quoted context omitted.
> why should I trust that you will ship flawless code 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!
> You shouldn’t, because no code of sufficient complexity is flawless. So why build an upgrade procedure at all, when you don't have to? > On the Ethereum blockchain (for instance) storage and smart contracts are tightly coupled. Sounds like an unforced error on these smart contracts' authors parts, and should not be used as an excuse to compromise the principle of code immutability. If the possibility existed that t…
Re: An engineer's observations on Web3 and its possibilities
#67‘Web3’ is just new window dressing on the same old crypto casino. “Get rich quick!” is the selling point
Original author here. Totally. I’m old enough to remember when Web 3 was the semantic web, so I guess I don’t put much stock in the label. And, personally, I’m really interested in crypto-less federated systems like Mastodon and some of the stuff the Indie Web community has built. I have no idea if those are, uh, web3 enough for web3.:-) As for the question of casinos, I think @pinboard’s description of Web 3 as “an…
edit: by inclusive, I mean adoption and funding. The wheel does not need to be re-invented, poorly.
Re: An engineer's observations on Web3 and its possibilities
#68Hi 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.
www.reddit.com/r/Web3skepticism
Re: An engineer's observations on Web3 and its possibilities
#69Re: An engineer's observations on Web3 and its possibilities
#70Earlier quoted context omitted.
Can you provide an example of someone claiming defi can provide solutions for loans? The best I can come up with logically is something like cardano's prism that effectively puts a persons encrypted identity on the blockchain which allows that person to reveal things like their grades etc. to future partners as a means of quickly establishing trust. Maybe something like that could enable defi loans? Even that is a st…
Searching for "DeFi loan" returns a deluge of results with https://defirate.com/loan/ at the top for me. They seem content claiming that secured loans are useful loans.