The Ethereum Paradox

[smooth]

I don't understand what you mean by censoring code. There is a virtual machine and the virtual machine instructions are all deterministic. There is no instruction that could produce a random value.

+

No, because you can't check time either, so you can't write that program!

Hmmm...

a) That sounds extremely crippled

I guess that is debatable. It isn't (marketing hype about "world computer" aside) intended to run all general programs. It is intended to run programs useful for smart contracts.

b) That sounds extremely broken if the result is ...forking (I'm not sure that it can keep things deterministic when there are tens if not hundreds of possible triggers for indirectly randomizing things).

Well it is risky, but there's a lot of effort behind making sure those triggers don't exist, multiple security reviews, etc. So far no one has found a way to do it, at least not in the wild.

[TPTB_need_war]

It's just an example, trying to understand how a random function would work.

Simple.

The entropy for the seed would come from the proof-of-work hash that wins the block. All other validators would respect this entropy.

Let's say randomizing numbers is out of the question.

It is not out-of-the question. The randomness of a number is determined by the source of the entropy. Proof-of-work has a high entropy.

No, because you can't check time either, so you can't write that program!

Hmmm...

a) That sounds extremely crippled
b) That sounds extremely broken if the result is ...forking (I'm not sure that it can keep things deterministic when there are tens if not hundreds of possible triggers for indirectly randomizing things).

The primary reason that smart contracts are basically useless, is because a block chain can't form a consensus about anything external, except for signatures transactions that are authorized by public key cryptography to modify block chain state. Block chains can only form a consensus about block chain state transformations with the clock period being blocks and the longest chain rule.

If it were possible to introduce state into the block chain that could not be objectively verified by all validators, then the Nash equilibrium is lost, a Prisoner's Dilemma is created, and consensus is no longer convergent.

Augur is an example of attempting to form consensus about external state (the outcomes of prediction markets) by employing reputation of participants. Essentially they attempt to build a new consensus system on top of Ethereum's block chain consensus. But the problem is those two consensus systems can not be orthogonal, because validators of Ethereum have to be able to agree on the objective state on the block chain of Augur data. Notwithstanding that the Byzantine Generals Problem can't be solved with reputation and propagation, due to Sybil attacks.

Everything Ethereum is a delirium. Delusional just like Vitalik staring off into blank space when he speaks.

[AliceWonderMiscreations]

Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.

When I first started programming the random function required a seed and always gave the same result with the same seed. We knew that random wasn't really random, but dependent upon the seed we gave it. How we changed that seed was critical. Increment by 1 or something predictable and the results were predictable.

Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.

There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.

[hv_]

Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.

When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.

There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.

... and is still not solved ...

[AlexGR]

The primary reason that smart contracts are basically useless, is because a block chain can't form a consensus about anything external, except for signatures transactions that are authorized by public key cryptography to modify block chain state.

I'm sure they have some not very widespread uses but the "virtual computer" concept is definitely useless, so far.

It can only form a consensus about block chain state transformation with the clock period being blocks and the longest chain rule.

Still, if the clock period is block, and, code-wise, can be used as a ...clock, then there is a clock.

So, say, I write a program which says "I add 42 to 42 to 42 to 42 ...until next block is found".

The result of the addition will be different for a slow vs a fast cpu (the faster cpu will have reached a higher number).

[TPTB_need_war]

Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.

When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.

There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.

... and is still not solved ...

An adequate entropy pool can be obtain from the user's mouse movements.

The problem is with the operating system's entropy pool and the API for accessing it. Avoid it entirely if you want to be very sure.

[AliceWonderMiscreations]

Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.

When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.

There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.

... and is still not solved ...

The biggest problem recently is not using blocking entropy source.

[AliceWonderMiscreations]

Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.

When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.

There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.

... and is still not solved ...

An adequate entropy pool can be obtain from the user's mouse movements.

The problem is with the operating system's entropy pool and the API for accessing it. Avoid it entirely if you want to be very sure.

Avoiding it entirely can be dangerous if you don't know what you are doing.

Lot of people in Linux land use /dev/urandom when they should be using /dev/random

On servers or fresh after install (when ssh key is generated) that's highly problematic. That was the fairly recent raspberry pi problem.

They don't want to use /dev/random because it blocks and may take too long and is a bad user experience but I think a key made from insufficient entropy can lead to a worse user experience.

But kind of going off-topic, I don't see ethereum as a platform for doing that kind of stuff anyway.

It will be continued issue with Internet of Things.

[hv_]

Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.

When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.

There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.

... and is still not solved ...

An adequate entropy pool can be obtain from the user's mouse movements.

The problem is with the operating system's entropy pool and the API for accessing it. Avoid it entirely if you want to be very sure.

Yep - than you'd need a human user in front of a miner

[TPTB_need_war]

Some people don't understand how random numbers work. Or that there are different qualities and kinds of randomness.

When I first started programming the random function required a seed and always gave the same result with the same seed. Modern languages often pick a seed for you if you don't, and people often assume that means there is some magic way for a computer to pull a number out of thin air.

There have been many exploits resulting from random numbers not having a seed that is selected from an adequate entropy pool.

... and is still not solved ...

An adequate entropy pool can be obtain from the user's mouse movements.

The problem is with the operating system's entropy pool and the API for accessing it. Avoid it entirely if you want to be very sure.

Avoiding it entirely can be dangerous if you don't know what you are doing.

Lot of people in Linux land use /dev/urandom when they should be using /dev/random

Accessing the blocking entropy pool has issues as well.

Doing anything expecting random numbers and not knowing what you are doing is going to result in failure.

On servers or fresh after install (when ssh key is generated) that's highly problematic. That was the fairly recent raspberry pi problem.

That is one of the corner cases. Now Linux I believes saves entropy between reboots. I don't remember all the issues. I would need to read up on it again. Afair one of the issues is we can't know the quality of the entropy in the blocking pool and we can't know if it has perfect forward security.

[smooth]

The primary reason that smart contracts are basically useless, is because a block chain can't form a consensus about anything external, except for signatures transactions that are authorized by public key cryptography to modify block chain state.

I'm sure they have some not very widespread uses but the "virtual computer" concept is definitely useless, so far.

It can only form a consensus about block chain state transformation with the clock period being blocks and the longest chain rule.

Still, if the clock period is block, and, code-wise, can be used as a ...clock, then there is a clock.

So, say, I write a program which says "I add 42 to 42 to 42 to 42 ...until next block is found".

No you can't. Programs can only look at blocks in the past, not the future and there is no "until a block is found" operation. More practically if there were, a program that tried to do a long-running loop like that would likely run out of gas (which results in state rollback and loss of gas). Programs have to be small and simple.

[YarkoL]

No you can't. Programs can only look at blocks in the past, not the future and there is no "until a block is found" operation.

Check Ethereum Alarm Clock

"An ethereum contract that facilitates scheduling function calls for a specified block in the future."

But you'd have to cap the number of your operations, true.

[TPTB_need_war]

Guarantees
Will the call happen?

There are no guarantees that your function will be called. This is not a shortcoming of the service, but rather a fundamental limitation of the ethereum network. Nobody is capable of forcing a transaction to be included in a specific block.

The Alarm service has been designed such that it should become more reliable as more people use it.

However, it is entirely possible that certain calls will be missed due to unforseen circumstances.

This is an example of what I was writing about upthread where I said externalities destroy the Nash equilibrium and create a Prisoner's dilemma for validators when there is sharding.

I am not going to write down the complete explanation. Just think about it.

(And remember from upthread that sharding is flawed for another more ubiquitous reason, which is the gas can't be sharded without destroying decentralized consensus)

[TPTB_need_war]

at least the main people should work too

Do Vitalik and Vlad "work"? Is delusional meandering work?

[smooth]

No you can't. Programs can only look at blocks in the past, not the future and there is no "until a block is found" operation.

Check Ethereum Alarm Clock

"An ethereum contract that facilitates scheduling function calls for a specified block in the future."

But you'd have to cap the number of your operations, true.

The Ethereum alarm clock doesn't work that way. Your program can't "loop and wait for the next block" the way AlexGR described. For one thing, the alarm clock events are a part of a separate transaction and only one transaction (logically) executes at a time.

[YarkoL]

The Ethereum alarm clock doesn't work that way. Your program can't "loop and wait for the next block" the way AlexGR described. For one thing, the alarm clock events are a part of a separate transaction and only one transaction (logically) executes at a time.

I haven't looked into the alarm clock closely, but it seems to
me that AlexGR's program could be done even without that service.

Something along the lines of

while (block.number != previous_block) x += 42

But as mentioned, there is no guarantee of this succeeding
as it is up to miners to include the tx.

This is an example of what I was writing about upthread where I said externalities destroy the Nash equilibrium and create a Prisoner's dilemma for validators when there is sharding.

But what is the externality here? Everyone can see that a new
block has been found.

[TPTB_need_war]

This is an example of what I was writing about upthread where I said externalities destroy the Nash equilibrium and create a Prisoner's dilemma for validators when there is sharding.

But what is the externality here? Everyone can see that a new
block has been found.

Disagreement about whether the transaction was included (and then disagreement about the derivative smart contract state transitions), which cross shards. Because not all validators validate all shards. The externality is that including a transaction or not is not deterministic but rather is determined by the longest chain rule, but there is no longest chain rule if each partition has orthogonal state (which must be the case if not all validators validate all partitions).

Indeed when there is only one partition, then there is no disagreement about how to merge state from partitions. But I was writing about the sharded case.

Remember the alarm clock is triggered by blocks, but shards don't have their own blocks. Thus the state of the alarm clock is cross-sharded state. It is an analogous reason as to why gas destroys decentralized consensus in a sharded design.

Vitalik has himself deep in a clusterfuck.

[smooth]

The Ethereum alarm clock doesn't work that way. Your program can't "loop and wait for the next block" the way AlexGR described. For one thing, the alarm clock events are a part of a separate transaction and only one transaction (logically) executes at a time.

I haven't looked into the alarm clock closely, but it seems to
me that AlexGR's program could be done even without that service.

Something along the lines of

while (block.number != previous_block) x += 42

No!

Transactions/contracts/programs execute within a block (by being included in the block!). The block number will never change during execution.

[TPTB_need_war]

Transactions/contracts/programs execute within a block (by being included in the block!). The block number will never change during execution.

The alarm clock works by saving a state on the block chain (recording the pending alarms), then it is invoked every time a smart contract invokes it to set an alarm. The alarm contract checks for any triggered alarms every time it is invoked by another contract.

But it is impossible for this to work with sharding and not destroy the decentralized consensus game theory.

[smooth]

Transactions/contracts/programs execute within a block (by being included in the block!). The block number will never change during execution.

The alarm clock works by saving a state on the block chain (recording the pending alarms), then it is invoked every time a smart contract invokes it to set an alarm. The alarm contract checks for any triggered alarms every time it is invoked by another contract.

Yes, and all of these events will all each occur within the context of one block (which includes the transaction causing them to occur). It is impossible to write a program that "executes until the next block" or whatever it was that was suggested.

But it is impossible for this to work with sharding and not destroy the decentralized consensus game theory.

Sure that's another issue.