Bottom line is that the block chain is applicable for recorded state transitions that can be proved to be correct from data internal to the block chain. It is not applicable to anything which requires subjectivity about data external to the state in the block chain.
So most everything people are proposing for Dapps, can't work without breaking the objective census mechanism and thus destroying the Nash equilibrium security of the consensus due to a Prisoner's dilemma over which is the consensus choice.
And validation will always end up centralized for any block chain (smart contracts or crypto currency) no matter which consensus design is chosen.
Ethereum will crash and burn eventually. For a while, they might be able to keep the market fooled with technobabble and centralized training wheels.
Topic: The Ethereum Paradox - page 25. (Read 99889 times)
Also sort of works, but has other issues. Even in the best case the cost will be high.
If you know a way to break the system, even a "high" cost can be pretty low.
I was unclear. I meant the cost (in terms of on-chain contract execution) to generate usable random numbers using this sort of multiparty protocol, not the cost to attack.
Also sort of works, but has other issues. Even in the best case the cost will be high.
If you know a way to break the system, even a "high" cost can be pretty low.
- Short the market (millions of dollars in a billion usd marketcap)
- Pay thousands of USD as a "price" to break it
- Break it
- Create market panic
- Close the short
Turn the "cost" to profit
The discussion was about a nondeterministic output for use as a random number generator. The suggestion was to loop (an unknown number of times) until the next block is solved. That can't be done.
My bad. Sloppy reading, sloppy day.
However, I still think you could use block hash(es) as long
as the cost of generating proof-of-work to meet some predetermined
sequence exceeds the benefit from doing so.
Yes, but unfortunately it is likely impossible to determine what benefit might be achieved (across multiple contracts). I think TPTB has commented on this.
Quote
More intricate attempt to get around this:
https://forum.ethereum.org/discussion/2031/randao-a-dao-working-as-rng
https://forum.ethereum.org/discussion/2031/randao-a-dao-working-as-rng
Also sort of works, but has other issues. Even in the best case the cost will be high.
The discussion was about a nondeterministic output for use as a random number generator. The suggestion was to loop (an unknown number of times) until the next block is solved. That can't be done.
My bad. Sloppy reading, sloppy day.
However, I still think you could use block hash(es) as long
as the cost of generating proof-of-work to meet some predetermined
sequence exceeds the benefit from doing so.
More intricate attempt to get around this:
https://forum.ethereum.org/discussion/2031/randao-a-dao-working-as-rng
In theory, nothing is. Our computers don't have infinite memory.
Good catch.
Doesn't the discussed problem mean that Ethereum is not Turing-complete?
In theory, nothing is. Our computers don't have infinite memory.
Doesn't the discussed problem mean that Ethereum is not Turing-complete?
As I said, all that will do is count how many times the contract is involved. How is that useful?
By incrementing, I meant adding 42 to a variable (ok, sloppy terminology again).
Not useful at all, but if I understood
you, you said it was impossible to do.
But perhaps you meant, impossible to
increment repeatedly within a single block interval.
No and it is not impossible to do that. A contract can be called multiple times in a block. It can also increment repeatedly during one execution. What it can't do is increment a nondeterministic number of times.
The discussion was about a nondeterministic output for use as a random number generator. The suggestion was to loop (an unknown number of times) until the next block is solved. That can't be done.
As I said, all that will do is count how many times the contract is involved. How is that useful?
By incrementing, I meant adding 42 to a variable (ok, sloppy terminology again).
Not useful at all, but if I understood
you, you said it was impossible to do.
But perhaps you meant, impossible to
increment repeatedly within a single block interval.
I'm not sure what you are trying to accomplish, but this will simply count how many times the contract is executed before it expires. Nothing random about that, its just a counter.
This
Quote
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".
So, say, I write a program which says "I add 42 to 42 to 42 to 42 ...until next block is found".
Although I'm not incrementing until next block (which would execute only once), but until block is
at certain height.
As I said, all that will do is count how many times the contract is involved. How is that useful?
I'm not sure what you are trying to accomplish, but this will simply count how many times the contract is executed before it expires. Nothing random about that, its just a counter.
This
Quote
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".
So, say, I write a program which says "I add 42 to 42 to 42 to 42 ...until next block is found".
Although I'm not incrementing until next block (which would execute only once), but until block is
at certain height.
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.
Ok, that was sloppy. When initializing the contract,
define cutoff = block.number + N. Then increment while
block number <= cutoff. And if you're lucky, you get to
do that N times.
I'm not sure what you are trying to accomplish, but this will simply count how many times the contract is executed before it expires. Nothing random about that, its just a counter.
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.
Ok, that was sloppy. When initializing the contract,
define cutoff = block.number + N. Then increment while
block number <= cutoff. And if you're lucky, you get to
do that N times.
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.
Quote
But it is impossible for this to work with sharding and not destroy the decentralized consensus game theory.
Sure that's another issue.
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.
Quote from: 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.
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.
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.
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.
Jump to: