Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An engineer's observations on Web3 and its possibilities

psl.com

Post reply on HN
Print view View original

131–140 of 319 posts

Re: An engineer's observations on Web3 and its possibilities

#131

Post by wyck »

davepeck wrote: post #57
manbart wrote: post #19

‘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…

I'm old enough to remember web 1, web 2, and web 3 , thinking web3 is a casino is ridiculously immature, it's how get rich quick moonboys and the mainstream media view blockchain, without actually spending the time researching the technology and understanding basic economic principles.

Re: An engineer's observations on Web3 and its possibilities

#133

Post by UncleMeat »

thebean11 wrote: post #58
v_london wrote: post #16

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…

Aren’t mortgages actually also examples of over collateralized loans? You borrow 80% of the homes value, and use the entire home as collateral.

You can live in the home while it is collateral. You can’t use your collateralized coins.

Re: An engineer's observations on Web3 and its possibilities

#134

Post by jt2190 »

jude- wrote: post #15

> 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…

> ...instead focus on getting the code correct the first time

This is a threshold that real-world contracts don't typically have to achieve. They leave lots of details out, or vaguely defined, because the odds are low that that part of the contract will have to come into play, and it's not worth the extraordinary effort and time and expense to negotiate every tiny very-unlikely-to-happen case.

To quote Lawrence Lessig [1]: "Often obscurity is a real value. Obscurity is what you want... In principle we should be negotiating all of these [possible things that could happen to our deal]... What contracts do all the time [instead] is they create these fuzzy or vague or ambiguous places as a gamble... And if it turns out [that this .002% occurrence does] happen, we'll ask... a judge to figure them out.

Also, if you're just going to replace one immutable contract with another, you're back to meatspace and re-negotiation, which can be time consuming and expensive.

[1] MIT 15.S12 Blockchain and Money, Fall 2018. "Smart Contracts and DApps" https://youtu.be/JPkgJwJHYSc?t=3543

Re: An engineer's observations on Web3 and its possibilities

#135

Post by PretzelPirate »

shiohime wrote: post #120
PretzelPirate wrote: post #116

Earlier quoted context omitted.

The problem is that Solana is much easier to attack. Imagine running a business on Solana and all an attacker has to do is bribe 700 (or fewer) operators to give your competitors a advantage. Those attackers can’t even be punished by slashing their stake. Solana is attractive to everyday users because it’s cheap to use, but it’s security isn’t suitable for high-valued assets (even self-verifying the chain is expensiv…

If you don't mind me asking, do you know of any good resources for learning more about the scalability solutions of Solana vs Ethereum? I've only been in the space for about 6 months as an engineer and almost every document I've read in regards to Solana scaling are sure that they will not encounter the same scalability issues that ETH has had. However, they are direct competitors so I wonder how biased these claims…

Here is a great article to read on why layer1 blockchain scalability isn’t sustainable long-term (for any layer 1): https://polynya.medium.com/why-rollups-data-shards-are-the-o...

When reading about competing blockchains, it’s important to figure out if someone you’re reading values money or decentralization (and therefore individual’s digital autonomy once we enter the Metaverse). Polynya (Liberosist on Reddit) is in the same camp as me - we want the most permissionless, secure, and censorship resistant solution. As an Ethereum Dev recently put it they want to build in the MSIT secure, decentralized blockchain and as long as Ethereum is the only one providing that, they’ll keep building on Ethereum.

It’s hard to understand which protocols are the most decentralized and secure because blockchains have gone from being built for decentralization, to being marketing machines. No one really writes about things like the importance of state receipts for blockchain validation, how many chains remove those due to the storage overhead, and how users lose a lot of self-reliance when that happens. I think they largely don’t write about it because most users nowadays just want to get rich and don’t care about decentralization, but I hope that changes and people realize that we need a neutral layer to store digital assets that we actually own as the Metaverse becomes a real part of our lives over the next 10-20 years.

Re: An engineer's observations on Web3 and its possibilities

#136

Post by wyck »

riffic wrote: post #67
davepeck wrote: post #57

Earlier quoted context omitted.

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…

The web3 movement should be be inclusive of IndieWeb and federated ActivityPub ecosystems. Interoperability and open standards paved the way for all of this, and it'd be a shame to toss that out of the window for some pie in the sky vapor. edit: by inclusive , I mean adoption and funding. The wheel does not need to be re-invented, poorly.

This is so wrong it's astonishing, web 3 is build build using principles and designs that are decades in the making, literally 30-40 years of cryptography, zero knowledge proofs, game theory, and advanced mathematics. It's incredible that these ideas and academic papers are finally becoming real. The web 3 movement is very inclusive, but technology moves forwards not backwards.

Re: An engineer's observations on Web3 and its possibilities

#137

Post by jude- »

davepeck wrote: post #64
jude- wrote: post #53

Earlier quoted context omitted.

> 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…

> So why build an upgrade procedure at all, when you don't have to? 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…

> Flaws, once known, can be remediated. I don’t think macOS has bulletproof security but I’m sure glad Apple keeps updating it.

My point is that a piece of software does not need an upgrade procedure if there exists a way to install a newer copy without touching the old one. Trying to build an upgrade procedure when there is always the option to install a newer version this way (especially if it can seamlessly access the older version's state) is at best over-engineering.

> Out of curiosity, how does this typically get exposed in dApps (or wallet UIs) built on Stacks?

This is being done right now with Stacks' on-chain naming system, which is realized as a smart contract. The new naming system does not need to import any state from the old system in order to resolve pre-existing names, nor does the existing naming system need to be disabled, because the new system is instead able to call the name resolution method via this "run read-only code on the chainstate as of this block" feature. The past is immutable, so future changes to the state of the old system beyond a predetermined sunset block (defined in the new contract) will not be visible to the users of the new system.

Consider this example. Suppose the name "alice.btc" was registered at block 1000 (hash 0x123) in the old system, and suppose the new system was deployed to use all the state in the old system up to block 1001 (hash 0xabc). Resolving alice.btc in the new system runs code to the effect of:

  (let (
    (alice-rec (at-block 0xabc
      (contract-call? 'SP000000000000000000002Q6VF78.bns name-lookup? "alice.btc")))
    )
    ;; Do something with alice-rec
  )
Internally, the (at-block) function runs the given code body with access to the system state as it was as of the end of block 0xabc. The system state is represented internally as a set of key/value pairs indexed by a forest of authenticated hash tries which make it efficient to query a key as of a particular block (see https://github.com/stacksgov/sips/blob/main/sips/sip-004/sip... for details).

Suppose bob.btc was registered in block 1002 (hash 0xdef). The above (at-block) call will not resolve bob.btc in the old contract, because its state was written after the sunset block 0xabc.

Re: An engineer's observations on Web3 and its possibilities

#138

Post by jude- »

frazbin wrote: post #66
jude- wrote: post #53

Earlier quoted context omitted.

> 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…

Being able to query arbitrary past blockchain history is kind of gross, because you can neither partition nor elide any of the data under consensus- your verifiers need to have a copy of everything. Leads to expensive nodes cause disk space and RAM use explodes. Not an uncommon complaint about immutable programming techniques generally. Idk, kinda seems like a bad tradeoff to me. But then again if you're building it…

> verifiers need to have a copy of everything.

Hate to break it to you, but if your consensus rules permit forks, then there's no getting around this. A fork can be mined arbitrarily far in the future that builds off of a block arbitrarily far in the past.

We intend to partition state by application, for applications that are willing to trade smart contract composibility for more block space: https://gist.github.com/jcnelson/c982e52075337ba75e00b799421...

> But then again if you're building it on top of the literal money fire that is bitcoin, who cares about scalability and resource use!

Show me a more resilient blockchain and we'll build on that instead. Popular systems see lots of usage; news at 11.

Re: An engineer's observations on Web3 and its possibilities

#139

Post by aspenmayer »

uncomputation wrote: post #125
aspenmayer wrote: post #121

Earlier quoted context omitted.

It’s possible you’re thinking of Chia, IPFS, or FileCoin, all of which are “live” and “deployed” currently.

Filecoin is “live” only technically. There is no way for individuals to contribute, which seems to be intentional as the leadership is looking for corporate support first. It currently has no real use cases. I say this as someone who is also excited by the idea.

Perhaps you can clarify the relations between IPFS and FileCoin? I was under the impression that they were related projects of Protocol Labs, with IPFS being a dependency of FileCoin.

Re: An engineer's observations on Web3 and its possibilities

#140

Post by jude- »

jt2190 wrote: post #134
jude- wrote: post #15

> 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…

> ...instead focus on getting the code correct the first time This is a threshold that real-world contracts don't typically have to achieve. They leave lots of details out, or vaguely defined, because the odds are low that that part of the contract will have to come into play, and it's not worth the extraordinary effort and time and expense to negotiate every tiny very-unlikely-to-happen case. To quote Lawrence Lessi…

> This is a threshold that real-world contracts don't typically have to achieve

And boy does it show!

How do you debug your smart contract? Your users tell you their money got stolen out of it. I wish that was a joke.

> Also, if you're just going to replace one immutable contract with another, you're back to meatspace and re-negotiation, which can be time consuming and expensive.

Is upgrading them in place somehow better? At least by keeping the old systems around, the people who still get mileage out of them aren't sold up-river.

Post reply on HN