[HN Gopher] An engineer's observations on Web3 and its possibili...
___________________________________________________________________
An engineer's observations on Web3 and its possibilities
Author : treblig
Score : 81 points
Date : 2021-11-23 19:16 UTC (3 hours ago)
(HTM) web link (www.psl.com)
(TXT) w3m dump (www.psl.com)
| jerrygoyal wrote:
| are there any other working examples of web3 except torrents?
| hervature wrote:
| Sorry, I'm not going to allow people to rewrite history and
| claim torrents are Web3. The technology is 20 years old and the
| most dominant protocol for file sharing.
| kordlessagain wrote:
| Meanwhile, distributed and/or encrypted technologies are enabling
| flash mobs to loot $200 jeans from Nordstroms.
| rvz wrote:
| Excellent post. Succinctly cutting through the crypto hype-squad
| and addressing the concerns, unveiling the shortcomings and
| outlining the possibilities of the current Web3 ecosystem.
|
| Highly recommended read.
| v_london wrote:
| Thanks for the great article! I wished the section on DeFi
| addressed the biggest elephant in the room,
| overcollateralization. A DeFi borrower always needs to lock in
| more assets as collateral than what they are borrowing, thus
| defeating the whole purpose for taking a loan aside from
| financial speculation. And there's no real way to solve it: all
| mechanisms I've heard of either try to replicate some form of
| background checks on borrowers (not decentralised, and uses the
| real world), or claim to use real-world assets as NFT collateral
| (once again, uses the real world). Thus I can't see a way for
| DeFi loans to ever be used for mortgages and other loans regular
| people actually need.
|
| Of course DeFi is more than just loans and borrowing, but that's
| an aspect that's constantly promoted by evangelists so I think
| it's an important point to mention.
| thebean11 wrote:
| Aren't mortgages actually also examples of over collateralized
| loans? You borrow 80% of the homes value, and use the entire
| home as collateral.
| viksit wrote:
| This is a great point. Some ways I'm seeing this addressed are
| in the form of,
|
| - Credit ratings from the real world being moved on chain, both
| by startups and by established companies (see Fitch report from
| Oct 21, pay-to-access only).
|
| - Credit ratings across and on chains
| (https://www.credprotocol.com/) to make sure that a defi OG on
| eth can have access to collateral on other chains.
|
| - Chainlink and others are working on products like CCIP
| (https://chain.link/cross-chain) to facilitate creating more
| systems like this through Oracles vs having to be reinvented.
|
| I would imagine this state of affairs gets better over time.
| toolz wrote:
| 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 stretch.
| hervature wrote:
| 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.
| getsprite wrote:
| Great job with this. Very nice overview.
| manbart wrote:
| 'Web3' is just new window dressing on the same old crypto casino.
| "Get rich quick!" is the selling point
| davepeck wrote:
| 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 unregulated casino with a hip bar scene" (sigh)
| strikes me as... about right?
| Animats wrote:
| Exactly. If Bitcoin had not gone "to the moon", all of this
| would be a tiny niche, like Chaum's DigiCash was.
|
| The problem is all the junk riding Bitcoin's coattails. At some
| point, probably soon, the bottom will fall out of at least part
| of this. NFTs are already crashing. That's not too visible,
| because there's no "market price" across different items. But
| you can look at sales on OpenSea, and notice that the resale
| prices are mostly lower than the previous price.[1] Smooth Love
| Potion [2], part of the Axie Infinity Ponzi, already crashed.
|
| The big moment will come when Tether comes un-tethered. It
| cannot survive a net outflow, because it has very little asset
| backing. Something is going to crack in the Tether/Binance
| area. Binance is giving some people 200x leverage.[3] That
| never ends well.
|
| [1]
| https://opensea.io/collection/collectvox?search[sortAscendin...
|
| [2] https://coinmarketcap.com/currencies/smooth-love-potion/
|
| [3] https://www.coalexander.com/post/the-tether-binance-axis-
| and...
| cornstalks wrote:
| > _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.
| im_down_w_otp wrote:
| I came hoping for a lack of hype and I left covered in confetti
| and glitter with a nasty black-eye from the rolled up T-shirt
| that was shot out of a cannon at me.
| yourabstraction wrote:
| I think it might help if you look at it in a slightly different
| way. While yes, crypto investors can capture the value of the
| network growth, this isn't the important point. Crypto
| protocols are fundamentally value storage and transfer
| protocols. So I think it's useful to draw a parallel between
| the protocols you listed above and the internet, which are all
| used for the storage and transfer of data. The internet/web was
| an immense success because it freed data from it's shackles,
| and allowed a more free and efficient flow of information. This
| allowed everyday users to publish information, apps, etc. and
| innovation to flourish.
|
| 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.
| machiaweliczny wrote:
| Not necessary negative from UX perspective. Can make economics
| of walled gardens less diserable as you can profit on protocol
| and have incentive to make best protocol possible. Time will
| tell.
| wmf wrote:
| The fat protocol hypothesis hasn't been proven. If your app has
| value, why would you let a protocol take any of it?
| krrrh wrote:
| It still really depends how far down the stack you go. One of
| the better observations Eric Raymond made in his essay The
| Magic Cauldron was that the closer you get to infrastructure
| the stronger the demands become for open protocols (emphasis
| added):
|
| > 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...
| davepeck wrote:
| This is great! I remember Raymond's post from my distant
| past. Thanks for bringing it to my attention again -- it's
| very relevant.
| machiaweliczny wrote:
| Because this allows to make bigger pie for everyone in the
| end. Not sure it does. Just speculating based on economic
| benefits of infra - see roads, transport, internet, aws etc.
| inshadows wrote:
| 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.
| davepeck wrote:
| (Original author here: I agree completely. I'm... one of
| those older hackers. That said, I'm also fascinated and,
| frankly, a bit alarmed by this sudden change in the balance
| of value capture and creation. I think it's worth looking at
| and contemplating face-on. That doesn't mean I like it!)
| newacc9 wrote:
| psl.com has a beautiful chocolate background, easy on the
| eyes, but this link in particular blasts my retinas with
| whitespace. Consider darkmode.
| dopa42365 wrote:
| I don't mind crypto as anonymous payment to buy illegal things
| online. And that's all it's good for, really.
|
| Shady gambling, scams and shitty art is not the future.
| danr4 wrote:
| Why in the name of the lord would you block my ability to open
| links in new tabs (on the main site)
|
| Edit: this site navigation experience is one of the worst i've
| ever encountered. I'm really interested in looking around but
| it's so painfully slow.
|
| Edit 2: the new tab is blocked on the main site, not on the blog
| post
| dang wrote:
| " _Please don 't complain about website formatting, back-button
| breakage, and similar annoyances. They're too common to be
| interesting. Exception: when the author is present. Then
| friendly feedback might be helpful._"
|
| https://news.ycombinator.com/newsguidelines.html
| SilasX wrote:
| "I learned it by watching you" where "you" = 90% of the web
| today, sadly.
|
| (That is, unnecessarily and avoidable breaks some links that
| should be thusly clickable even if some still can be.)
|
| How we got to this point, I have no idea.
| davepeck wrote:
| (I'm not having trouble with that and I certainly don't intend
| to block you; what os/browser are you using?)
| danr4 wrote:
| linux/chrome, ctrl + click / middle click not working.
|
| Edit: on the main site, blog post links work fine
| jimkleiber wrote:
| On main site, macos/ff, cmd + click doesn't open in a new
| tab either.
|
| However, right click, open in new tab does work.
| davepeck wrote:
| Thanks for the report. Definitely annoying. On the list
| to fix.
| officeplant wrote:
| What in lords name kind of browser are you using? (working fine
| here in chrome/ff)
| Animats wrote:
| It's a good article. Much to think about.
|
| I'm not sure that "blockchain" is central to "Web3". "Web3" may
| be augmented reality, which doesn't need a blockchain.
| byeager wrote:
| A pretty comprehensive overview that covers a lot of ground in
| the crypto/Web3 landscape.
| otikik wrote:
| > If the crypto economy has productive ends, they must ultimately
| rest here
|
| Seeing this put as a conditional is refreshing after all the
| hype.
| machiaweliczny wrote:
| I think the biggest potential might be in creating companies and
| contracts. I would love smart contracts that with given payment
| also give me some shares of company.
|
| Also investing in pre IPO for retail investors in scam-resistant
| schemes.
|
| Public funding of projects. Voting with ones wallet but
| formalized and outliers and spam resistant.
|
| Ability to profit from and measure public goods thus allowing to
| employ Capitalism there and get rid of EU bureocracy. One can
| dream.
| pcthrowaway wrote:
| These things already exist in forms. Take a look at DAOs
| obarthelemy wrote:
| I almost read the thing, but I can only read so many words in
| that horrendous font. Is this representative of the substance vs
| form stance of web3 ?
| jude- wrote:
| > 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 can't be upgraded. Ever try to upgrade the firmware on a
| chip with no I/O facility for doing so? The answer is you don't;
| you instead focus on getting the code correct the first time, and
| possibly you build out a way to recall the product and replace it
| with a fixed version and price in the risk of needing to do so
| into the product itself. It can be done; it just takes
| discipline.
|
| Second, if you don't understand why smart contracts being
| immutable is a necessary and desirable _feature_ of the system,
| not a bug, then you 're not going to understand much of web3.
| Like, think about it for five minutes -- if your smart contracts
| can be upgraded by default, and this code manages valuable
| digital assets, then their code can be replaced with code that
| steals those assets. Making this _very, very, very hard_ is
| deliberate.
| davepeck wrote:
| 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.
|
| I'm not the only one. For instance, the primary USDC contract
| on Ethereum is a proxy contract -- it's upgradable by design. I
| think that makes a lot of sense, and apparently so do the
| engineers managing those many billions of dollars: they've
| weighed the balance of "trust" in the abstract with "make sure
| it doesn't break" in the real and made their decision.
|
| Beyond that, a guiding principle of some newer blockchains
| (like Tezos) is that code will need to evolve over time. Like
| many things Web3, it's too soon to tell how things will shake
| out in the long run, and a variety of approaches seems
| desirable.
| sharemywin wrote:
| I think that's what's interesting about "blockchains" versus
| on specific chain.
|
| 1. polygon is a cheap(as in transaction fees) knock off of
| Ethereum, competition good. bad from the perspective of
| capture value in the protocol.
|
| 2. as far as I can tell as long as one oracle doesn't become
| dominate that provides competition
|
| 3. Defi is enabling users value across other networks.
| uniswap, etc.
|
| 4. On a side note, not sure why there's not an api that
| encrypts an nft on ipfs and only returns the watermarked
| version unless you send it a fee. or your the owner.
| toolz wrote:
| because it's not a real problem. The same way you can buy a
| mona lisa t-shirt in the gift shop and that doesn't steal
| any of the value away from the owner.
|
| What you describe could be rather easily implemented, but
| why would anyone build or use that?
| serverholic wrote:
| 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.
| davepeck wrote:
| 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-...
| jude- wrote:
| As a user who might prefer the first version of the code
| to the second, why should I be excited about a software
| system that can force me to use the upgraded version?
| That's a _design flaw_ in the current Web -- when a Web
| service I rely on changes its behavior and goes out of
| business, I 'm SOL. Web3, with _immutable_ smart
| contracts _that stay online_ , has the potential to fix
| this.
| toolz wrote:
| 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.
| davepeck wrote:
| Yes, 100%. It's one reason why I mentioned Tezos: it has
| upgradability and upgrade governance built in from day one,
| which -- if nothing else -- I think is an interesting
| design point.
| Animats wrote:
| _For instance, the primary USDC contract on Ethereum is a
| proxy contract -- it's upgradable by design._
|
| By whom?
|
| "Upgrading" a contract should require the approval of all
| parties to the contract.
| davepeck wrote:
| Right. In the case of USDC, whoever has the private key to
| their proxy contract's owner account. You're trusting their
| engineering team to do the right thing.
|
| (EDIT: if I'm reading my etherscan correctly, it's account
| 0xfcb19e6a322b27c06842a71e8c725399f049ae3a with upgrade
| rights. Sorry, I'm in transit so tapping on my phone.)
| jude- wrote:
| > 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, 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.
| davepeck wrote:
| > 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!
| jude- wrote:
| > 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 they need to replace the
| business logic at a later date, then they should factor
| the storage logic so as to avoid this coupling. It can be
| done -- for example, a smart contract dapp can leverage a
| shared contract that only implements a public key/value
| store, where the keys are prefixed by the calling
| contract's address. Then, when the business logic
| contract changes, it can access any old versions' state
| with the old versions' contract address, apply any
| migrations on-the-fly, and store new state that _will
| not_ overwrite old state due to this key prefixing.
|
| 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). Then,
| you don 't even need to do any migrations -- you can just
| query the historic state of your old contract and only
| store new data once it's necessary.
| frazbin wrote:
| > 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.
|
| 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.
| rodiger wrote:
| It's not very, very hard currently though. It's just slightly
| more complex and more error prone. Most complex DeFi protocols
| are upgradeable by design these days.
| davepeck wrote:
| 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.
| tmaly wrote:
| Great notes! I am curious, what language / tech stack would be
| most promising in this space?
| machiaweliczny wrote:
| AFAIK only EVM(Ethereum VM) is popular and others are
| emulating it. You have Soldity there which is meh from my CS
| view. On frontend you use whatever you like and just bind via
| library to wallets.
| clpm4j wrote:
| Thanks to you and your colleagues for writing this - the best
| writeup I've come across so far. This puts all of a16z's crypto
| marketing babble to shame.
| davepeck wrote:
| Thanks; I'm really glad to hear that!
| bla3 wrote:
| > Hype-Free
|
| > It's a hip bar in a club that a cooler friend had to tell you
| about.
|
| Ok then.
| davepeck wrote:
| Hah! I do think there is an aspect of "cool club" that, whether
| successfully or not, the Web3 community wants to get across.
|
| I'm an outsider to that community. Perhaps @pinboard said it
| less hypefully when he described it as an "unregulated casino
| with a bar scene attached".
___________________________________________________________________
(page generated 2021-11-23 23:00 UTC)