Evolution of the Ethereum proof-of-stake consensus protocol
github.com
github.com
One thought it does raise in my mind, though - this is complicated.
Bitcoin is simple. The rules are simple. Simple is really good when it comes to securing a currency.
This, in comparison... I mean, oof. I get the high-level "proof of stake" idea, which (in my mind) has a similar mental complexity to Bitcoin's. But all the algorithms that need to work to support it... it introduces the idea in my mind that somewhere in one of those algorithms is a small oversight. Even if that's not the case, the thought is there.
My opinions on proof-of-stake hasn't changed (seems much better than PoW in real-world use for so many reasons) but it does seem to erode the beautiful simplicity of proof-of-work.
Also, you can't even unstake your eth. The developers promise it's coming soon, but right now, you can't.
Vaccines and cars and everything else you hint at have been around a long time and the trade-offs are pretty well understood. Proof of stake (and it's various implementations) have a long way to go before they reach that status
On the other hand the hotstuff protocol is much more easy to grasp IMO (check my explanation in the book Real-World Cryptography)
PS: oh and also Bitcoin proof of security seems like a nightmare. It’s nice to create protocols that look simple but if you can’t prove their security it’s a bit dumb :) on the other hand the safety proof of hotstuff is quite comprehensive : https://www.davidwong.fr/lbft_safety/
I had to look up hotstuff proof of stake. As far as I can tell that's not what Ethereum (the coin we are discussing here) uses? Not sure where you are going with this.
Bitcoin is not complicated until you try to implement it yourself and prove it.
Compared to the likes of Ethereum, Bitcoin is super simple. Compared to others, it's still somewhat complicated.
While the use of PoW for consensus is super simple (most cumulative difficulty wins), Bitcoin script is a huge source of complexity in itself, with tons of warts. As it turns out, you don't need script to do payments, multi-signatures, atomic swaps, discreet log contracts, bidirectional payment channels etc., i.e. nearly all of the functionality that script is used for. All those can be done with so-called script-less scripts [1], which is mostly creative use of Schnorr signatures.
Bitcoin's emission is not that simple either with the reward halvings every 4 years. A fixed block subsidy (i.e. pure linear emission) is not only simpler, but arguably fairer too, avoiding a concentration of wealth on early miners/adopters, and leaving later generations more than mere crumbs.
[1] https://suredbits.com/schnorr-applications-scriptless-script...
Yet Ethereum had a premine of around 60M, roughly half of all existing coins today. Later emission seems negligible regarding fairness.
In terms of fairness of coin distribution, 100% PoS < Ethereum < Bitcoin < Pure Linear Emission.
PoS effectively ends the distribution of new coins, with everybody able to stake to just preserve their share of the pie.
With both PoS and PoW, a holder loses share when the total coin supply increases. On Ethereum at least, this is less of a problem with staking than mining, because staking is less costly so there's a tenth as much issuance.
However, with sufficient usage, the ETH supply actually shrinks, because a portion of fee revenue is burned. This means non-staking holders actually increase their share.
You can see how that's going here: https://ultrasound.money/
You are not supposed to buy ETH as a way to speculate on its price.
ETH is a resource used to represent processing and storage power. You can think of it as "AWS credits" that you can buy and use to run programs.
The absolute price of ETH is of no interest. The only meaningful number that you should care about is "what is the gas price compared to the ETH price", as in, "how expensive is it to access decentralized computing".
Speculating on ETH value is an investment strategy that is completely separate for ETH utility. People interested in the latter shouldn't care about the former. Just as people using AWS shouldn't really care about AWS stock price.
It might add a lot of implementation complexity, but in terms of conceptual complexity, it's pretty easy to understand at a high level.
I also don't find bitcoin halving complex to understand either. Whether its good is a separate question.
I think it’s quite well written and worth a look.
The halving is probably the reason for the high tides of Bitcoin prices and the inflow of capital to all of cryptocurrency.
Its faster! Its new! Its more advanced!
Strikes me as strongly analogous as to why each of us doesn't run our own email server? Which is, when email was first invented, may have not seemed like a bad idea, but in terms of scale something like federation works better?
Someday there will be another doctrinal conflict with a near 50/50 split in the community. Probably for the same reason - some DAO hack too massive to ignore. In a proof-of-work world, we can evaluate the health of each fork by measuring the scarce physical resources allocated to each.
In a proof-of-stake world, each fork can have a valid voting majority of stakers. There's no actually-scarce resource to split, so no external mechanism to decide which fork is the "real" one.
I wouldn't bet a potential future world monetary system on this scheme.
So what really happened when a PoS chain forked? Justin Sun learned the hard way.
In contrast, in PoW, there's nothing stopping miners from creating a hostile fork that is economically advantageous to them (despite maybe being "worse" overall) and then flipping back to the original chain if their fork doesn't work out. Their hash power can't be slashed in the same way stakers ETH can be in PoS.
If you do change the chain id, then by definition your chain is the new and different one, because it has a different id.
> Slashing is triggered by the evidence of the offence being included in a beacon chain block. Once the evidence is confirmed by the network, the offending validator (or validators) is slashed.
It is a powerless mechanic if the majority of validates don’t want to play along.
A chain is defined by a set of rules that everyone on the chain agrees to abide by. Braking the rules damages the economic utility of the chain, so the Ether on the chain where the validators colluded to break the rules would be worth less, as a result of their actions. The validators are locked on that chain (as they can't prevent a fork from excluding them), so they have a strong incentive against harming the chain. Ethereum is not majoritarian. I don't have to abide by the will of the majority. I only need to come to a consensus about the rules and state of the chain with the people with whom I want to share the chain.
PoS makes it much easier to escape a malicious majority compared to PoW where the hashing power majority can follow the minority anywhere unless the minority is willing to switch to a different hashing algorithm. Even then, the majority could sell their mining equipment and buy new equipment that will work on the new chain on the same terms as that chain's honest minority can. With PoS, the malicious majority would need to buy new Ether from the honest minority who can then just fork again after having made a profit on the attack, and can continue to do that until the malicious majority runs out of resources or realizes that they cannot censor a fork in Ethereum's PoS system.
So you’re going to create a new fork, remove the money from the majority of the wealthy stakeholders who are governing the system, and expect this one to be be seen as legitimate? The one that is explicitly giving the finger to the wealthy?
Good luck!
While I don't think it's meaningful to say that one chain is more legitimate than another, if I was forced to make such a deamination in this case, I would consider the chain where the rules are consistently and predictably enforced in a way that leads to predictable outcomes more legitimate than a chain where validators have colluded to arbitrarily subvert the enforcement of the rules.
The majority of validators could perhaps block this by all running forks of the various consensus client software, with some code changed to set the reward to zero, but why would they do that?
[1] https://github.com/ethereum/consensus-specs/blob/dev/specs/p...
If we imagine a 90/10 split of opinions that leads to a hard fork, the 90 majority can either be satisfied and with their fork and be nice or they can stonewall the 10% fork and refuse to approve any blocks that supports the idea that they deserve to be slashed. Because the only thing that can punish the majority is the approval of the majority. And because allowing another fork to exist reduces the value of the other forks. And because it would just be nicer if instead of having two forks we just kicked out all those annoying validates we don’t agree with.
If the 10% wants to fork off and do a completely different blockchain, what happens to the folks who aren’t colluding either way? I mean, while we’re down to just throw away people’s stakes, why not do so for everyone who isn’t explicitly on our side?
For example: migrating to a new chain ID and restarting with a validator set limited only to the public keys of the 10% who are acting honestly, and loosening that restriction slowly over time.
The attack would end up being extremely costly: not only because it makes the original chain’s token price worthless (who wants to be on a malicious chain?), but because the attacker may also have their deposit slashed in the new chain by the now-majority of honest users defending it.
Genuine question: how does that work? How does ETH mainnet know that my validator is also voting on a different chain?
Don't cite me on the details, but that is the idea
Assume I could have obfuscated the move through the many means availible.
Basically a dispute that allowed to sell the same bitcoin twice?
Here you potentially have a way to sell the same eth tokens few times. Revolutionary!
What might eventually happen is that some % of the validators exit Ethereum mainnet and enter their deposit into an another blockchain, perhaps giving it a different name and set of features and tradeoffs.
More details:
https://ethereum.stackexchange.com/a/591
https://blog.ethereum.org/2015/08/01/introducing-casper-frie...
45% of validators sign on fork A
45% of validators sign on fork B
10% of validators sign both A and B (coincidentally such that they get evenly slashed between the two)
1) to validate, instead of just sitting doing nothing
2) to choose the chain with the most likely chance of being the next main, otherwise they will be slashed
As soon as even the slightiest imbalance appears between the two forks, it will bias validators to choose one against the other and thus exponentially make it the preferred fork.
I think this is actually the most commonly overlooked assumption. The protocol seems very robust, *assuming* perfect information (aka all incentives are known to the system).
I encountered this problem a few years back when trying to design a protocol for a decentralized prediction market. It's very hard to account for hedges or huge bets on other markets.
These would have to have different network or chain IDs to avoid slashing events. One of them, presumably B, would have had to actually change this number from whatever the previously standard/agreed-upon chain ID is.
I could imagine this scenario happening in a contentious split or attack, but it would create two very clearly different blockchains with different goals and needs, like what happened with Eth and EthClassic, or Eth and EthPoW.
The key is in the fact that violating the rules on Ethereum's PoS causes you to lose Ether, which means you eventually lose all your Ether and can no longer sabotage the chain. This is in contrast with PoW systems, where your mining hardware doesn't deteriorate any faster just because you are mining empty or invalid blocks, so you can do that forever and effectively shut down a chain that is small enough relative to your computer power. The only defence a PoW fork has against such an attack is to switch to a different algorithm that is less compatible to the attacker's hardware, but that harms non-attacking miners just as much. PoW has an element of "might make right" while PoS is completely consensual.
If anything happens, the fork anointed by Vitalik will prevail. Otherwise, ETH is doomed. Quite simple, really…
Simple protocols take time to land, and are often digestions of much more complicated protocols. We’ve seen that with TLS being simplified into Noise, or the sponge function for hash functions. If you look at the history of consensus protocols they are getting simpler and simpler as well, arguably hotstuff and streamlet and all the hotstuff variants are simpler and simpler to understand.
It's bizarre to me that people wrote a contract that says one can take the money in certain circumstances, but then completely refused to abide by that.
I really feel bad for the person who figured out how to get the money but then was denied by insecure bullies. What an absolute joke.
I know you can join cooperatives for this purpose, but then it’s not your crypto anymore and this space is filled with thieves and con artists.
It’s something I’ve been kicking around as an idea for a while as part of a diversified portfolio, if eth drops to a point where I could afford 32.
I’m extremely skeptical of cryptocurrencies, but eth is the best of them and the network transaction volume is supposedly in the neighborhood with Visa ( something I find hard to believe.)
I think the PR line is that PoS ETH can “scale to 100,000 TPS”, but it’s currently pushing 15-30 [1]. Visa does much more, though various figures are reported from 1,750 to 24,000. So, grains of salt and all that.
Important to note that Ethereum embraces the idea that L2's will provide a lot of the scale and L1 will remain the base, main layer of security. So the goal isn't for L1 to scale massively, but to be able to support a healthy ecosystem of secure L2's which scale in different ways!
For one, Visa just does funds transfers. If Ethereum just transferred ETH, it could do 700 tx/sec, based on the gas limit per block divided by the 20K gas for a simple ETH transfer. A lot of Ethereum transactions are more complex and use more gas.
Second, second-layer "rollups" already support transaction rates up to a couple thousand per second, without losing base-layer security guarantees. Essentially they compress the transactions on chain. (Actual traffic is much lower than that, so far.)
The longer-term plan is to move to rollups in a big way, and add a form of data sharding to multiply the on-chain data storage. That's where the 100K/sec comes from.
So... Still an order of magnitude less than Visa.
> A lot of Ethereum transactions are more complex and use more gas.
How complex are they, are they a significant number, and dies this explain the abysmal transaction rates?
Visa aside, on Singles Day AliPay does 1 to 1.5 billion transactions in one day.
Okay. AliPay is an outlier. Klarna does about 2 million transactions per day, an average of 23 per second (it's significantly higher during peak hours, and lower during off-peak hours. Source: worked at Klarna). The transaction includes: client lookup (a complicated affair that differs from country to country and session to session), credit score calculation, order set up, payment (out of a several dozen different options) set up... all while conforming to banking and local regulations across 45 countries. Anything in eth anywhere close to that complexity-wise?
> Second, second-layer "rollups" already support transaction rates up to a couple thousand per second
So layer 2 batches transaction into a batch that then gets batched on layer 1 into a bugger batch that is then written in one go to the blockchain.
Congrats, you've reinvented batch processing.
How complex? -> Turing complete. Also there is more to L2s than batching. Their aim is to maintain the security guarantees of the L1 without sacrificing availability. Plus, Zk proofs and merkle trees allow for great data compression in the rollup.
I stopped making an effort five-seven years ago for many obvious reasons.
> How complex? -> Turing complete.
Ah yes. Unlike every other system in the world that isn't?
Turing completeness isn't a feat. It's such a trivial thing that people arrive at it by accident.
Now the claim was "ethereum is abysmally slow because it runs complex things". What complex things are there that warrant this abysmal performance?
> Also there is more to L2s than batching. Their aim is to maintain the security guarantees
Yeah, yeah. It is batching for any intent and purpose. Do you really think batching in "traditional" systems is done without guarantees etc.?
You take a push down automata (finite state automata plus a stack) and then add the ability to read and write anywhere in the stack.
The essence of Turing completeness is the ability to take any intermediate result as an input to the computation of the next result.
This is why the halting problem is even a problem, because you need all of the intermediate results to know the end result.
Ok now back to the topic at hand. Turing completeness on the L1 layer isn't very impressive because every node is supposed execute the code to validate it. The problem with L2 then is the fact that you must somehow avoid that, i.e. the L2 layer executes the smart contract and determines a result and these results are batched on the L1 where the point is that you're not supposed to execute the contract as otherwise there is no speedup to be gained. It is sort of a paradox.
The end result has to be verified on chain. The most promising strategy so far is build a zkEVM which produces a zero knowledge proof that can be verified on L1 via a smart contract.
I still don't understand how this convinces people to buy Ethereum.
Money is supposed to be a medium of exchange because barter is expensive and time consuming. Instead of trading anything for anything we trade anything for money and money for anything. Competition is good but is Ethereum even competing?
How exactly do random wealth transfers to early adopters serve any purpose that money is supposed to be used for according to classical text books?
> Congrats, you've reinvented batch processing.
This is an extreme over-simplification of zero knowledge proofs. You would do well in digging deeper what is being achieved instead of dismissing it without any understanding.
There's a gulf between "can run" and "actually runs".
So what exactly is so complex that Ethereum runs that it processes stuff so slowly?
Blockchains are designed to meet the most extreme requirements of availability, censorship-resistance and cost of attack. They achieve them by exploring the extremes of replication of the solution space of distributed systems. For example, Ethereum runs on a Raspberry Pi, and every node runs the exact same things. Therefore how fast it goes is limited to the slowest node you want to make able to run the blockchain.
But, what you are dismissing as simple batch processing are the application of very novel techniques (novel as in math was invented in the last 5 years to make them possible) that allow to externalize most of the heavy computation outside the blockchain and delegate to the blockchain the verification of a proof. Therefore allowing to inherit the security properties of the blockchain but achieving much higher scalability.
Ethereum settles nowadays 200 bitcoin equivalent transactions per second. And is targeting to scale to 1-10M transactions per second by 2030.
All of those "oh my god complex things" on Ethereum are a variation of "look up a single number in one account, look up a second number in the other account, add or subtract two numbers".
Even doing a KYC + proper credit check on a client will cripple Ethereum.
> that allow to externalize most of the heavy computation outside the blockchain and delegate to the blockchain the verification of a proof.
So, batching. But with an extremely complex processing that you trust devs implemented correctly.
> Ethereum settles nowadays 200 bitcoin equivalent transactions per second.
No one cares about "equivalent transactions" to be honest. People care about actual things being handled by actual transactions they engage in.
The good news is that there’s a lot of room for improvement in the design. The bad news is twofold: (1) efficiency improvements will eventually cause transaction processing to be data-bound rather than compute-bound, and (2) these improvements to improve compute may be incompatible with existing Ethereum nodes. ZK and optimistic rollups potentially offer a way out of this update mess that don’t require dramatic changes to the underlying consensus system. However they will also inherit some of the limitations above, including tradeoffs between availability and processing speed.
This is probably the first reply I've seen that doesn't shy away from saying "yes, we're inefficient", and looking at the solutions with a critical eye.
Nothing against the talented devs working at Klarna, but if they have trouble handling the load, they can always add a couple TB of memory or a couple hundred CPU cores.
Ethereum needs to solve 100k tps while continuing to run on a Raspberry Pie on a home internet connection.
Ouch. Burn :)
A lot of fat has been trimmed from Kred and it's now rammed into an AWS instance, but the pain is real :)
> Ethereum needs to solve 100k tps while continuing to run on a Raspberry Pie on a home internet connection.
To run a node you need a 2TB disc, at least 16 GB of RAM and a quad-core CPU. So, not on Raspberry Pi yet (and probably not ever).
This is just an example, there is plenty other hobbyists doing so.
And here detailed instructions for you to try at home: https://docs.rocketpool.net/guides/node/local/prepare-pi.htm...
So, for a single combination (Geth + Nimbus) it may just be possible to run this tower of babel on a Raspberry Pi. And.... The only thing it will be doing is... nothing, really.
Current network demand doesn’t really require them, but after EIP-4844, “100 000 TPS” should be possible.
Given that they successfully transitioned an entire consensus change and things didn't implode (yet), I'm feeling a bit more optimistic that they can do withdrawals.
Testnets already happening. Q1 2023 on the table.
Bitcoin has the lightning network based on Bitcoin smart contracts that can do Visa-like rates of Visa-like transactions. I don't know if Ethereum has anything like that.
Then there is a very helpful community called EthStaker - they have a subreddit at r/ethstaker and a discord (invite should be available in the subreddit).
If you want something a little more automated, Dappnode is a well regarded web based front-end and the Rocketpool node stack makes things very easy to be an operator for their pool using a TUI.
There are a lot of options, with a wide range of requirement and capabilities.
[1]https://www.coincashew.com/coins/overview-eth/guide-or-how-t... [2]https://someresat.medium.com/ [3]https://eth-docker.net/
Choices are: use custodial staking (share your keys with custodian - risky), use non-custodial staking (keeps your keys private but has costs e.g. Lido charges 10% of your staking rewards), use an L2 coin (risks), use a financial proxy for Etherium (ugggh).
I guess running your own node means you can’t use a cold wallet, so security costs/risks are high?
Rocketpool is non-custodial, allows you to run your own node with about 17.6 eth (16 eth + 1.6 eth worth of their token), and then earn a commission from the folks contributing the other 16 eth and not running a node. There is a decent amount of smart contract risk and risk around the value of the token, but it is a generally working protocol.
> I guess running your own node means you can’t use a cold wallet, so security costs/risks are high?
To answer the security concern - The staking keys can only be used for validation activities, and can't be used to spend the funds. When depositing the stake, you can specify a normal ethereum address where withdrawn funds will go to, and that address can be controlled with a hardware or cold paper wallet/signer. The worst an attacker who compromised your node and took your staking keys could do is get you slashed (a little more then a 1 eth penalty in normal circumstances), which would be of no benefit to them.
Or maybe do some of the “Byzantine validator” attacks in the paper?
Thank you for the staking keys info - I find it difficult to grok crypto systems.
You don't need five nines of uptime, you need like, two.
You don't get subject to slashing for your node going offline, you only get slashed if your node is doing shit out of consensus like actively cooperating in double spends.
Look up "inactivity leak". If enough staked value (>1/3) is offline, those nodes get slashed until >2/3 of the total stake is online again.
For software Rocketpool has a really nice guide + configuration GUI, and you only need 16eth for it and you get more rewards than from a normal staking node. It's still fully self custodial.
Why do the first two images after the LMD-Ghost section [1] look like they were made on an iPad? All the other images are made using proper tools. I didn't realize that the letter in the first image was a V because it looked like a N. Feels slightly inconsistent.
[1] - https://github.com/ethereum/pos-evolution/blob/master/pos-ev...
Yeah, that totally won't backfire.
What’s the real difference, other than lag time for PoW?
Can you reword this? Not quite sure what you're asking
i need something basic, like alice and bob contract to sell 100 watermelons for 1 BTC and sarah is the arbitrator in case they have a problem... something like this.
or a smart contract to validate a sale of a house for 2 BTC.
or a partnership deed for a business between alice and bob with 3 clauses
anyway try scaffoldeth.io
you compile the tutorial website first and then build a bunch of common smart contract scaffolding
note this is the EVM ecosystem so it would be impossible to conflate example in pure BTC, smart contracts are playing catchup in BTC ecosystem. There are a couple competing attempts there, very little scaffolding. There are many orders of magnitude more activity in the EVM ecosystem than there are in bitcoin ecosystem/UXTO model smart contracts.
People recommend ethernauts[1] and cryptozombies[2], but I found those quite slow when I was learning. Most useful for me was reading existing implementations of smart contracts, and learning from there.
M1guelpf wrote these a while ago, might be helpful examples: https://github.com/m1guelpf/lil-web3
happy to chat if you need help
After developing the contract, use something like Truffle Suite to validate that the contract is good, and add a testing suite around it.[1]
Find a test net for the coin that you're developing for and create an account. Generally testnets will allow you to have "play money" to work with. This will allow you to learn how to deploy your contract to the testnet (which is functionally identical to mainnet)
Deploy it there, test it further. Write apps around it with tools like web3.js or eth.js as appropriate.
Buy some currency for the applicable mainnet and deploy your contract to mainnet just as you did with testnet, only this time it'll cost actual currency to deploy -- this will vary wildly by network and token and such.
This guy's videos are pretty helpful: https://www.dappuniversity.com/articles/the-ultimate-ethereu...
Different tokens have different protocols and such. The above works for Eth and Eth-based tokens. Cardano is Haskell-based, and refers to smart contracts as programs, and the process is wildly different. Some other tokens use Rust, or other languages, but the BASIC outline I've laid out is basically the same no matter which (except for Cardano, which may be the same, I have no idea.)
What you can do is anything that is related to moving ETH or ERC tokens/NFTs between addresses.
So an example that you see often is a Kickstarter type contract. This contract collects ETH from many sources over a period of time but will only pay out to the payout address if the minimum is reached in that time period. Otherwise all the funds are returned. This contract is fully autonomous and can be validated to do what it is supposed to do. You don't have to trust a single company like Kickstarter to follow the rules or not cancled your compain. The project being a scam or not compleeting is another story.
So in other words what you can do in a smart contract are financial constructs that are zero trust.
The reason many scams happen is also in part that people are not checking that the contracts are solid and prevent rug pulls etc.
Which is why they're useless except for implementing complicated financial schemes. Which, in practice, are mostly scams.
Come to think of it, though, it doesn’t even guarantee that. The person who created the contract and will get the funds if the minimum is reached could always just send ETH from one of their other own accounts to trigger the threshold.
If the contact enforces that when $tokenAmount is sent to $address, $asset is sent to $depositor.
If and when more things exist on the blockchain, and/or more physical institutions sign on to it, and/or more and more digital goods are worth transacting in such a fashion, then smart contracts will make more sense.
If neither of those materialize more tangibly than they do, it'll be hard to manufacture use cases for it, I think (though I am hardly an expert).
But considering the types of things that are already mostly digital, it seems like we have the _potential_ to lean into the latter case. Domain names, accounts, Github subscriptions, e-books, music, rights to watch movies / television shows, etc., those things could all be integrated into the blockchain and enforced via smart contracts easily.
Probably the best use case I've seen is stadium / conference tickets, but if we ever get to a phase where companies significantly adopt, we can do some interesting things, like communal ownership of assets. Ownership stake can be variable, depending on who is doing the most work. Profits could then conceivably be distributed among those who have earned it the most. "What to do next" could be a decision that is decided upon by a council of token-holders, for better or worse, and truly non-managerial workers could meaningfully participate in a company's decision-making, profit-sharing, etc.
The main benefit I would see from the venue's perspective is in both scalping prevention and achieving price equilibrium with less effort, because smart contracts can allow a rake to be collected on each resale of a ticket. Beyond that, while this use case doesn't appeal to me, I know of people who've collected scrapbooks of concert tickets, but the NFTs of the tickets are a collectible item (to whatever extent someone deems a digital asset "collectible") and can be potential collected in a digital scrapbook as either social proof or memoria.
That said, there's nothing in my view that mandates that the central authority doesn't own the whole thing. You can own the whole thing, either on your own token, or as a non-blockchain product altogether -- or not at all, but there are existing tools and technologies that allow for easier on-ramps than building it yourself and I think most venues don't particularly care what the technology is or that it's NFTs or that it's blockchain, so I don't know of any reason that a blockchain based offering couldn't find itself competitive in the marketplace unless their sales pitch is exclusively that.
The main reason is that you have shown exactly zero reasons why anyone shold adopt it in a space that's already mostly solved the issue of selling tickets to people. You are teling people to create insane complexity just to solve the single case of selling a single ticket to a single person and pretend that's all there is. And telling people "but it's blockchain so it's good actually". That's not how this works, that's not how any of this works.
I did literally the opposite of that when I said "I don't know of any reason that a blockchain based offering couldn't find itself competitive in the marketplace unless their sales pitch is exclusively that."
Restated, I am saying that "but it's blockchain so it's good actually" is not a viable sales pitch. All the rest of my comment are reasons that I think are pitchable features.
You seem to have imagined me saying something I didn't and are arguing against what you've imagined I said.
So what are the reasons that a a blockchain based offering could be copetitive in the marketplace? And what would bockchain have to do with it?
Remember ,we're talking about tickets: a problem largely solved. Where a central authority you trust releases a ticket, and where the central authority you trust verifies the ticket at the venue.
So, what is the sales pitch for tickets for a blockchain-based ticketing startup? Other than, you know, "but it's blockchain!" (as all these startups do)
From another comment you've made "I stopped making an effort [appreciating a pro-blockchain point of view] five-seven years ago for many obvious reasons," I won't bother to re-list them. If you aren't going to engage in good faith because you've imagined me to be a crypto-proponent, I'd appreciate it if you'd at least read what you're trying to argue with.
Oh, I have. None of those are tangibl benefits to either the venues or to the consumers. Or are not issues to begin with. All you propose is to build a tower of babel to kinda maybe solve minor issues.
I especially like this: " smart contracts can allow a rake to be collected on each resale of a ticket." Ah yeah, let's milk money for ever, and ever, and ever.
As to collectibel items and NFTs, you don't need NFTs to make collectible items. Especially considering how actual data for this bullshit is always invariably stored on a centralised server somewhere.
But sure. "Benefits".
That's one of the many reason why I stopped making an effort [appreciating a pro-blockchain point of view] five-seven years ago. Because all the bullshit that crypto absolutists come up with is so far removed from reality. And that's even for the simplest use cases like selling one ticket ot a single person for a single concert.
Resales already happen now, so your "money forever and ever" counter-argument isn't particularly persuasive, and if there are going to be resales, _of course_ the venue would prefer to get a commission. That is a real market problem now, and there exists a real solution for it.
"Tickets are a solved problem" rings as intuitively spoken as "nobody will ever need more than 640K"
Despite your imagining otherwise, there are undoubtedly non-blockchain solutions that can be built here to solve those real problems, but there are real solutions to them now that for whatever reason you refuse to entertain because the answer contains the words block and chain contiguously.
Well, if the shoe fits...
> if there are going to be resales, _of course_ the venue would prefer to get a commission. That is a real market problem now
There are so many things wrong with this.
1. You assume that as matter of indisputable fact that venues are absolutely entitled to a cut on any ticket resales, in perpetuity.
2. You assume that people reselling tickets (and venues not getting a cut) is a problem. It isn't, really. This is somewhat true for a very tiny number of very popular events, and even there there are ways to mitigate it. The hundreds of thousands of events that happen around the world that require the ticket don't have this "problem".
3. It's telling that you assume that it's the venues that have to get in on the cut. Not the concert organisers. Not the actual people in the event (artists, sports teams, presenters etc.)
4. Of course, as with all "solutions" involving blockchains it doesn't solve anything. You transfer a ticket to another person for free, and get the money for it in a different transaction. You transfer credentials for the wallet which bought the ticket to a person, you get money in a different transaction. Etc.
5. Of course, as with all "solutions" involving blockchains, this one exclusively focuses on a single issue (which is largely inexistent in the grand scheme of things) to cater to the simplest of all the cases (selling a single ticket to a single person). And all this "solution" does is: make it extremely complicated and complex, not really solving anything, and making other legitimate use cases even more extremely complex or impossible (because ticketing is much more than just selling a single ticket to a single person, even if it's the biggest use-case).
> "Tickets are a solved problem" rings as intuitively spoken as "nobody will ever need more than 640K"
This is observable reality. There are hundreds of thousands of events that require tickets around the world (probably even on any given day). You buy a ticket, you go in, done.
It is a solved problem.
> solve those real problems
You have to show that it's both a) a real problem, and that b) what you propose is an actual solution, not a "well, if you squint hard enough and ignore reality, it barely works for the simplest of cases, if at all"
> or whatever reason you refuse to entertain because the answer contains the words block and chain contiguously.
The only reason I refuse to entertain them is because you keep failing to show how it is a solution to anything. Given the list of issues I listed above that are immediately obvious to anyone with half a brain and a grasp on reality.
And yes, that is an issue with almost literally anything that has "block and chain contiguously".
It doesn't
> venues are absolutely entitled to a cut on any ticket resales
No I don't. Moreover, "in perpetuity" is a red herring.
> you assume people reselling tickets is a problem
No I don't. I perceive it as a problem venues are willing to pay to solve.
> It's telling that you assume that it's the venues that have to get in on the cut
Again, no I don't. Anyone on the supply side of this can negotiate this in. The tickets can originate from the artists, and then the organizers, and then the venues. Artists and venues can openly negotiate on this.
I've said before that you're imagining things I'm not, and halfway through your response, that's all you've done. I'm not going to bother to read or reply to the rest.
Happy holidays.
You could for instance have 5 independent oracles responsible for validating whether the concert happened or not. The "ticket" smart contract would release the money only if the 5 oracles agree it happened, or refund the buyers otherwise.
Chainlink is much more sophisticated than that and handle oracle reputation, cross chain oracle proof, conflict mitigation, etc.
So, trusting centralised data providers.
> You could for instance have 5 independent oracles responsible for validating whether the concert happened or not.
Ah yes. Because the ticket is validated after the concert has happened, and not, you know, at the entrance to the venue.
And also so many "coulda/woulda"s in your description of something that has already been solved and doesn't require mountains of compleiy on top of it. I mean, you can't reliably show how having a single ticket to a single concert would work better than the existing system. And that's the simplest thing that can happen to a ticket.
Can we just stop this and act like engineers and actually _try_ to understand each other?
> So, trusting centralised data providers
Where did you understood that? Did you even read the comment you're replying to?
Chainlink (being just one example of an oracle protocol to illustrate the discussion), allows you to choose how many oracles you want, with whatever reputation constraint you want, strictly named or open ended, with or without whistleblowing/conflict mitigation algorithm, etc.
How does that deserves a snarky "So, trusting centralised data providers"?!
> Ah yes. Because the ticket is validated after the concert has happened, and not, you know, at the entrance to the venue.
There are multiple ways to handle this, a lot of future crypto contract implement something very similar to:
- The venue issues tickets that can be purchased through posting money to a smart contract.
- The smart contract locks in the money until, say, 5 oracles validate that the concert did happen.
- The venue can prove the locked in ticket sale amount as collateral to borrow money in preparation of the concert.
- The oracles validate that the concert happened, unlocking the sale money to the venue.
or
- The concert was a scam, oracles do not validate that it happened, thus ticket sales are refunded.
> something that has already been solved and doesn't require mountains of compleiy
My comment is not about the rationale or utility of the concert ticket example. It's about how that could be implemented with a smart contract.
> And also so many "coulda/woulda"s in your description
Chainlink is already used since multiple years to secure billions of dollars of pegged tokens, sport bet results, election results, insurance, etc.
Let's do that. I only wish these blind crypto absolutists would actually look at real world from time to time.
> Where did you understood that?
From your statement: "You can have hybrid smart contracts, that rely on oracles inserting real world data on chain"
Oracles are always cenralised data providers that you trust. And for may, many, many applications there will be only a handful of them.
> There are multiple ways to handle this, a lot of future crypto contract implement something very similar to:
Again. None of these are much of an issue for existing systems. Have you been to a real concert in the real world lately? You buy a ticket, you go to a concert, done.
No need for "five oracles to validate that a concert happened". There are hundreds of thousands of concerts happening all around the world without this inanity. What exactly does blockchain bring into this equation? Or "smart" "contracts" (which are neither smart nor contracts)?
> It's about how that could be implemented with a smart contract.
Indeed. That's what I was addressing. You wanted to talk like real engineers trying to understand each other? So try to understand this: you are proposing a mountain of complexity to solve what is largely a non-issue.
Your entire description on how ticket sales happen have literally no basis in the real world. And that's on top of the fact that you completely ignore what the original comment (and then I) said: your ticket is issued by a trusted central authority, and then is validated at the entrance by a central trusted authority. What does blockchain bring into this euation except lots of "coulda shoulda oracles"?
Edit:
Even in the cryptoutopia world the "contract" for the ticket will of course be released by the central authority running the concerts, and you'll have to trust that they didn't screw up the programming. And no, "you can always check the contract" doesn't work since there are now multiple cases of these "smart" "contracts" passing multiple security audits and still having glaring holes in them. A human-readable cotract you have with the concert organizer can actually be audited by regular people, and is enforceable.
> Chainlink is already used since multiple years to secure billions of dollars of pegged tokens, sport bet results, election results, insurance, etc.
Of course it did none of that.
This would be a great thing for blockchain proponents to start doing, yes. HN is littered with threads where people have spent hundreds of comments trying to get someone to explain how a blockchain is better than the status quo, and it always devolves to “I need to sell my random hashes”, usually with a side of “I have done no research into the domain I’m trying to sell into”.
Concert tickets are a great example. There are no widespread problems with tickets being sold for concerts which don’t happen and refunds being denied in violation of the terms of sale. Similarly, people don’t have any trouble paying for tickets since the existing options are cheap and safe. Those problems certainly aren’t large enough to warrant the additional cost and risk of using a blockchain.
The actual problem with concert tickets in the U.S. is that one company has exclusive contracts with most of the venues, their agents handle bookings for most popular bands, and they have a comfortable relationship with the company which controls radio play in much of the country. If you want to do anything in this space you need to understand that it’s not a technical problem, and explain what you’re doing differently which will succeed unlike the various failed attempts since the beginning of the web.
6. The theory is to dispel the myth that blockchain is a fringe technology used only by those wanting to risk their livelihoods or possibly make their fortunes on volatile cryptoassets like Bitcoin.
7. The blockchain is now at a stage in its development equivalent to where the internet was in or around 1995. The internet was unstoppable in 1995 and blockchain technology is unstoppable now. It will become ubiquitous in all major industrial and financial sectors, simply because it allows for the immutable recording of data, thereby reducing friction in commercial and consumer transactions and obliterating the scope for dispute as to what has occurred.
8. As the Master of the Rolls and Head of Civil Justice in England and Wales, I hold an office that pre-dates modern trade in derivatives and reinsurance, even steam engines, powered flight, and certainly the internet. I am particularly and obviously concerned about the reputation and development of English law and the jurisdiction of England and Wales.
9. Many people do not realise that English law governs trading in €600 trillion of OTC derivatives annually, in €11.6 trillion in metals trading, in £250 billion in M&A deals, and in £80 billion in insurance contracts every year – just to take a few examples. My hope is that English law will prove to be the law of choice for borderless blockchain technology as its take up grows exponentially in the months and years to come.
https://www.judiciary.uk/wp-content/uploads/2022/02/Speech-M...
That's why the judge's quote is relevant. They don't see a distinction between regular contracts and smart contracts. It's all just contracts.
I'm simplifying slightly (see Ricardian Contracts if you want the detail).
That is not some that any of those quotes states. The thrust of those quotes is focused on the value of the blockchain as an immutable ledger, and doesn't mention "smart contracts" once.
The statement you are trying to dispute seems to be pretty widely accepted. Once you need to refer to physical world events, you need yo trust some entity to report those events accurately, removing the trustless aspect of "smart contracts" that is their primary selling point.
The most you can read into the quotes that you posted is that the judge sees a strong future for the UK judiciary in resolving disputes about trust when "smart contracts" have to interact with the offline world.
I would also point out that "smart contracts" are not literally contracts, but pieces of trustless software. Conflating those concepts does nothing to help the uphill reputational battle that faces the cryptocurrency ecosystem given all of it's shenanigans.
Ah yes. It's the people's fault that they don't check code in esoteric programming languages running on esoteric VMs using made up words for everything.
Sometimes it feels like Urbit...
Not really true, though you can at least look at the code for all the good it'll do most people.
>alice and bob contract to sell 100 watermelons for 1 BTC and sarah is the arbitrator in case they have a problem... something like this
You create an owner variable that is used to show who can withdraw from the smart contract and is set to 0 at the start. You add 2 methods. The first is a method that is only usable by Sarah that lets her change the owner variable. The second is a withdraw function that is only usable by the owner. You can even enforce that the owner can only be set to Alice or Bob if you want.
Bob deposits 1 wrapped BTC. If Alice gives him the watermolens Sarah sets Alice as the owner. If Alice doesn't Sarah sets Bob as the owner.
>a smart contract to validate a sale of a house for 2 BTC.
You don't need a smart contract for that. Every transaction already gets validated by the network.
>a partnership deed for a business between alice and bob with 3 clauses
This depends on the clauses but you would put all the company assets into the smart contract and then write methods that let you spend those assets while not violating those clauses.
Of course. Just don't listen to the extreme ones, who continue to screech and parrot the same old absolutist takes over and over again to the media for engagement farming.
The truth is crypto is here to stay, but not all of them are going to survive. Only a few projects and cryptocurrencies will still be around longer than others and both crypto maximalists and anti-crypto absolutists are going to end up compromising in the end.
However, there are many other valid criticisms of crypto. So that's a weird strawman you're setting up there.