The Ethereum Paradox

[hv_]

You got it with your edit.

Of course the virtual machine assumes they are atomic as you first stated, but the reality of the sharding is they can't be.

Building the virtual machine was the fun, easy part. The consensus scaling was the hard part which they should have done first even before raising ICO money. That is disgraceful.

The only way around this that I can see is to make Ether non fungible, which is a bit of a problem for a currency.

Than the circle is closed since they initially said it's not a ccy, but fuel.

[1714031894]

1714031894

[TPTB_need_war]

You got it with your edit.

Of course the virtual machine assumes they are atomic as you first stated, but the reality of the sharding is they can't be.

Building the virtual machine was the fun, easy part. The consensus scaling was the hard part which they should have done first even before raising ICO money. That is disgraceful.

The only way around this that I can see is to make Ether non fungible, which is a bit of a problem for a currency.

Even that wouldn't work because as you pointed out, the entity running the script pays the gas, and that entity can not in every case have its gas balance in the partition that validates the script.

But gas never was going to work economically any way, because all the validators need to be compensated, not just the one who wins the block. Any means of equal sharing the gas between all validators will be Sybil attacked (again any arguments about changing this reality via consensus-by-betting would return to the fact that proof-of-stake or deposits are self-referential and all that entails). And any non-equal sharing means the consensus becomes centralized over time according to the rule that the one with the most resources has the most economies-of-scale.

[ilia7777]

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

[stoat]

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

Its pathetic really,  an ill (mentally and physically) and extremely jealous (old) man pouring incomprehensible and entirely premature FUD on software that no one knows the inner workings of because it isn't even released yet.


Apparently casper wont work because of some obscure mathematical principles which only this self proclaimed genius is able to understand and is incapable of explaining.

[StinkyLover]

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

Its pathetic really,  an ill (mentally and physically) and extremely jealous (old) man pouring incomprehensible and entirely premature FUD on software that no one knows the inner workings of because it isn't even released yet.


Apparently casper wont work because of some obscure mathematical principles which only this self proclaimed genius is able to understand and is incapable of explaining.

But yet this FUD troll 'crypto genius in his own head' will milk it for all it's worth with very long posts that no-one wants to read

[TPTB_need_war]

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

I ask you first where is the code example in Satoshi's white paper which explains a 51% attack? Hint: there isn't one because it doesn't have anything do with any specific implementation code, but rather is a mathematical structure.

Why don't you try to articulate what parts you understand and what parts you don't, then I will elaborate once I see where your blind spot(s) are. If you are unwilling to do so, then I will presume you are trolling (from a newbie account with 2 posts) as are the other panic-stricken trolls.

[hv_]

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

Not really needed, just watch that ETH-DEVs video upthread and try to get just a faint feeling for how close they are to a proper solution for Casper.

[ilia7777]

TPTB_need_war its really hard to follow your arguments without specific example. If you understand this deep enough give us specific code example which will illustrate what you are talking about. Without an example it seems very high level abstract esoteric discussion.

I ask you first where is the code example in Satoshi's white paper which explains a 51% attack? Hint: there isn't one because it doesn't have anything do with any specific implementation code, but rather is a mathematical structure.

Why don't you try to articulate what parts you understand and what parts you don't, then I will elaborate once I see where your blind spot(s) are. If you are unwilling to do so, then I will presume you are trolling (from a newbie account with 2 posts) as are the other panic-stricken trolls.

For starters explain what do you mean by saying that gas can't be partitioned ?

[monsterer]

Even that wouldn't work because as you pointed out, the entity running the script pays the gas, and that entity can not in every case have its gas balance in the partition that validates the script.

All the balances would have to be local to the partition and not shared - effectively like a fork of ETH for each partition.

edit: I'm considering the possibility of whether an inter partition transfer of ETH would be possible if the partitions merged once during the transfer and then split apart again post transfer block.

[TPTB_need_war]

Even that wouldn't work because as you pointed out, the entity running the script pays the gas, and that entity can not in every case have its gas balance in the partition that validates the script.

All the balances would have to be local to the partition and not shared - effectively like a fork of ETH for each partition.

And then how would a user who has his gas in partition 536 run a script that runs only in partition 1279?

Hint: he can't. Thus you would have entirely broken Ethereum with your suggestion.

edit: I'm considering the possibility of whether an inter partition transfer of ETH would be possible if the partitions merged once during the transfer and then split apart again post transfer block.

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

You even agreed with this upthread wherein you stated that validators can't decide which block to mine on if they don't validate all transactions in the block.

Edit: in case this isn't clear, let me remind readers and you that I had explained upthread that when validator that is responsible for validating only his own partition has to accept a spend from a partition he did not validate, then he has no way to know if that balance from the other partition was a lie or not. Thus he can't accept it, because his reward may be compromised if later it is shown that he accepted an invalid balance from a partition he did not validate.

[ilia7777]

Let me ask a stupid question here. How a user can have gas in one partition and not to have gas in another ? Are you saying that a user had spent his gas but it didn't get validated by the system ?

[monsterer]

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

You even agreed with this upthread.

I agree in general, but I wonder if there is more to this than it first seems. Yes it is true that merging two partitions into a block will need the block producer to validate both partitions to construct his new block, but that's not to say he necessarily has to keep validating both - if the partitions split apart again afterwards, for example that wouldn't be necessary.

You could formalise this such that an inter partition spend requires the source and destination partitions to merge for the transfer block only, thereby defining a partial order and only incurring an ephemeral increase in validation costs.

[TPTB_need_war]

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

You even agreed with this upthread wherein you stated that validators can't decide which block to mine on if they don't validate all transactions in the block.

Edit: in case this isn't clear, let me remind readers and you that I had explained upthread that when validator that is responsible for validating only his own partition has to accept a spend from a partition he did not validate, then he has no way to know if that balance from the other partition was a lie or not. Thus he can't accept it, because his reward may be compromised if later it is shown that he accepted an invalid balance from a partition he did not validate.

I agree in general, but I wonder if there is more to this than it first seems. Yes it is true that merging two partitions into a block will need the block producer to validate both partitions to construct his new block, but that's not to say he necessarily has to keep validating both - if the partitions split apart again afterwards, for example that wouldn't be necessary.

You could formalise this such that an inter partition spend requires the source and destination partitions to merge for the transfer block only, thereby defining a partial order and only incurring an ephemeral increase in validation costs.

And then the partition that has accepted the transfer of gas from a partition that it did not validate now will have all its derivative transactions (and scripts) subject to reversal if later someone shows evidence that the balance was a lie.

You are writing nonsense (and you should know it which is why I am not being entirely polite ... please don't feed the damn trolls because you are not careful to think before typing).

[stoat]

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

You even agreed with this upthread.

I agree in general, but I wonder if there is more to this than it first seems. Yes it is true that merging two partitions into a block will need the block producer to validate both partitions to construct his new block, but that's not to say he necessarily has to keep validating both - if the partitions split apart again afterwards, for example that wouldn't be necessary.

You could formalise this such that an inter partition spend requires the source and destination partitions to merge for the transfer block only, thereby defining a partial order and only incurring an ephemeral increase in validation costs.

And then the partition that has accepted the transfer of gas from a partition that it did not validate now will have all its derivative transactions (and scripts) subject to reversal if later someone shows evidence that the balance was a lie.

You are writing nonsense.

Vitalik and co. Will shard gas all over your nonsense FUD.

[monsterer]

And then the partition that has accepted the transfer of gas from a partition that it did not validate now will have all its derivative transactions (and scripts) subject to reversal if later someone shows evidence that the balance was a lie.

You are writing nonsense (and you should know it which is why I am not being entirely polite ... please don't feed the damn trolls because you are not careful to think before typing).

Read what I wrote again more carefully

[stoat]

Do not reply to the panic-stricken technologically illiterate trolls.

How am I panic stricken.  I'm loving life right now.  You're the one who is literally dying of stress

[TPTB_need_war]

And then the partition that has accepted the transfer of gas from a partition that it did not validate now will have all its derivative transactions (and scripts) subject to reversal if later someone shows evidence that the balance was a lie.

You are writing nonsense (and you should know it which is why I am not being entirely polite ... please don't feed the damn trolls because you are not careful to think before typing).

Read what I wrote again more carefully

Read what I wrote again more carefully. And make a rebuttal if you have one. Adding noise to the thread by writing this "read again" doesn't help at all. I read it already. I already explained why it doesn't make any sense. Where is your nonsense rebuttal?

Edit: for the source and destination partitions to merge (even for the history and not the future), means they need to validate each other's history. That is my point that then separate validation is lost. Thus the entire scaling advantage of partitioning is lost. Read again what I wrote! How can you not remember something I wrote just a few posts above:

I already explained that cross-partition spending is possible (i.e. won't destroy the Nash equilibrium) only if validation of all partitions is done by all validators, which thus defeats the scaling advantages of making partitions (shards).

[TPTB_need_war]

Let me ask a stupid question here. How a user can have gas in one partition and not to have gas in another ? Are you saying that a user had spent his gas but it didn't get validated by the system ?

I need to start by explaining everything about block chains. You are ostensibly lacking the very basic levels of technical understanding. But there are no stupid questions if they are sincere. Probably many readers would have a similar confusion.

Normally the way a block chain works (whether it be proof-of-work or proof-of-share) is that there is one ordering of transactions and blocks that the system forms a consensus on. The key point is that every validator validates every transaction and every block, thus each validator can be sure that there is nothing invalid is the consensus ordering. Note that any particular ordering is arbitrary as there are other orderings that are also valid, but the consensus chooses one ordering from the many arbitrary valid possible orderings. The consensus never chooses an invalid set of transactions nor an invalid ordering.

But when every validator has to validate everything, then the block chain can't scale and remain decentralized.

So Ethereum proposed to shard (partition) the validation such that scripts are assigned to a partition and can only operate on block chain state that has been validated for that partition. Any state stored on the block chain for other partitions is only validated for those other partitions. In short, partitions can't share state, because the validators can't assume that state they did not validate is valid. Because such an assumption would put the validators in a Prisoner's Dilemma game theory wherein the Nash equilibrium collapses.

So thus gas balances being a block chain state could only be spent within their own partition. So thus if you as a user have your gas balance stored in partition 536 and you want to run a script in partition in 1279, then you can not (not without entirely breaking the mathematical model of the security of Ethereum).

The only way to fix that is to not do sharding. Period.

Thus Ethereum can't scale decentralized. Period. There is no fix they can do (at least not anything they are contemplating ... although I have an idea of how to solve this problem with unprofitable mining but I am the only person with that idea).

[stoat]

Do not reply to the panic-stricken technologically illiterate trolls.

I'm technologically literate enough to tell that your arguments don't amount to anything

[TPTB_need_war]

Do not reply to the panic-stricken technologically illiterate trolls.