18
Here's code that waits specified number of blocks and verifies the transaction receipt is still valid. If a fork occurs and the replay fails, the receipt check should fail and the callback will call with Error set.
I've only tested this for success and timeout failures, I've not tested it on an actual fork of the blockchain, because I haven't figured out ...
16
So, the geth monitoring-node first seems to have imported the same one as reported above:
Jan 06 23:29:21 geth-testnet: I0106 22:29:21.064938 core/blockchain.go:1073] imported 1 blocks, 14 txs ( 0.348 Mg) in 19.168ms (18.180 Mg/s). #296151 [779e9f95…]
A hash 0x779e9f9558143be43f3eeb58ad1aa7764a03cf7f1bda4d1c29c2e1244d5e606f.
Then, a bit later on:
...
15
There are a few modules around that let you keep track of the "state" of a transaction (unconfirmed, X confirmations, conflicting transaction exists and is being confirmed, fully confirmed, definitely failed) and represent this info in the UI with color-coding. You should then probably only make "irreversible" changes to the data that's represented in the UI ...
6
Blockchains based on Proof of Work are probabilistic, and as more blocks are built upon the block containing a transaction, the probability of a chain reorganization removing that block and transaction becomes extremely low.
can/should I check it regularly, and if it still not exists after a "big" number of blocks, alert the user that their transaction is ...
4
I can't comment whether there is or is not a function for this in web3. What I do know is that Geth and Mist have transaction replay. This means that in case of a reorganisation it will process transactions that were 'lost' during the reorganisation so in theory the state should still be the same.
4
According to Ethereum White Paper transactions of orphan (uncle) will be added to the chain anyways.
As described by Sompolinsky and Zohar, GHOST solves the first issue of
network security loss by including stale blocks in the calculation of
which chain is the "longest"; that is to say, not just the parent and
further ancestors of a block, but also ...
3
The behavior in Ethereum is the same as in Bitcoin. At first the transactions seem to have gone through, but after a better chain is found it is as if the txs never happened.
3
From looking at the block stats on etherscan over the last 20 days, it looks like there are approximately:
475-525 single depth reorgs per day (uncle blocks)
1-2 reorgs with depth of two per day
I didn't see a single depth of three or more reorg
These numbers will probably go out of date soon. Only a few months ago there were days with 2,000 uncle blocks a ...
3
Currently I don't think there is a way to do that. Currently the docs say to just wait 12 blocks to make sure that a hard fork didn't happen and use getCode(). https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethcontract
2
You simply need to pick a confirmation limit that you are happy with. A common one in the ETH ecosystem is 12, so you would only consider data 'safe' if it was mined at least 12 blocks ago. You can check this is the case simply by fetching your latest block number, then subtracting 12 and calling that your latest 'safe' block.
2
On web3 API, section contract events, it is said that the object given to the callback has a removed field.
If you listen for your event and a reorganization occurs, you should be notified by an event in wich removed is set to true.
I never tried this but if understood correctly the doc, it should work.
2
Yes. But the exact circumstances are hard to pin down as it varies between nodes.
Each node on the Ethereum network will maintain it's own finite list of pending transactions. This is configurable on a per-node basis. Since the list is of finite size, if enough new pending transactions are received on the node or from other nodes, some transactions are ...
2
In a chain reorganization the order of the transaction can change, some transactions can be removed, and new ones added replacing others.
Since the log order follows the order of the transactions a chain reorganization can cause the logIndex to be different.
Moreover it is possible some events disappear from a block and appear again later if the ...
2
Just to follow on from Daniel's answer, here's a crappy Python scraper to scrape Etherscan and count the number of ephemeral forks of different lengths.
Results:
Forks of length 1: 6526
Forks of length 2: 164
Forks of length -: 85699
(Note: I think the - values are from older blocks where the depth data wasn't being recorded by Etherscan... so of limited ...
2
I don't know of a way to accomplish that with TestRPC. There might be a better way than described below.
I think I would make a private chain with Geth and low-difficulty/fast blocks in the genesis block.
Connect two nodes to each other and make sure both are mining and synchronized. Deploy your contracts, set up accounts and balances (they will each ...
1
It wouldnt be possible to do it with test rpc as it only mints blocks when transactions arrives, and isnt connected to other remote nodes, so there would never be discrepancies between nodes.
We have done this recently using private chains and some chaos tool .. pumba. Pumba will allow you to kill nodes, restart them and introduce latency and drop packets.
...
1
As the application developer, you need to handle this yourself. There's a little documentation here.
You send (and get returned) a queryId. You should check that this is valid inside your __callback() function when it is called.
You need to do this anyway, as the callback is public and can be called by anyone - so it could be an attack vector by a ...
1
Partial answer...
When it comes to smart contracts, how smart contracts deal with this kind of revert/rollback problems due to chain reorganization?
The smart contract itself doesn't need to deal with anything: it will be as though the transaction never happened, and no state changes occurred.
What might need to be dealt with are any changes that happen ...
1
Just to add to @Daniel's great answer: the amount of necessary confirmations depends on the needed amount of surety. How sure does the party need to be that the block won't get reverted?
As noted, single block reorgs happen all the time. Anything beyond that reduces the chances of revert drastically, per every extra depth.
Basically if you'd have data ...
1
If you want a reorganization free testnet, try Kovan. Ropsten is proof of work, and anyone who can point enough hashpower to it can rewrite the chain for a considerable number of blocks. Kovan is proof of authority, which ensures there are no reorganizations.
As for dealing with them on the mainnet, the general approach is:
On each new block, check the ...
1
If the chain is reorganised then any transactions contained within blocks in the 'old' chain will not exist.
This blog post outlines reorganisations in more detail.
"Roughly speaking, the chances of a reorganisation occurring reduce substantially the farther from the end you get.". This is why exchanges require 'x amount of confirmations' prior to ...
1
A reorg is done only if a block being imported on a side fork leads to a higher total difficulty on that particular fork than the canonical fork. The blocks nonetheless still need to be valid.
As written in the Ethereum blog, Chain reorganisations happen when a node on the Ethereum network realises that what it thought was the canonical chain turned out not ...
1
Manually add some well-reputed peers/bootnodes. The following guide runs through how to do this using geth, either via IPC or a config file: https://github.com/ethereum/go-ethereum/wiki/Connecting-to-the-network
1
If reorgs happen are you are subscribed with the PUB/SUB feature
{"id": 1, "method": "eth_subscribe", "params": ["newHeads", {}]}
You will start to get new blocks.
1, 2, 3, 4, ...
And on reorgs the same previous blocks will be returned. For example
1, 2, 3, 4, 2, 3, 4, 5, ...
Notice that 2, 3, 4 were sent a second time. This means they were reorged.
...
1
For the first question, according the docs, what you get should be as follows.
Say the last 3 blocks you mentioned are called a, b, and c, and the 4 new blocks are A, B, C, D. It should be that
a, b, c, A, B, C, D
because it says
In case of a chain reorganization the subscription will emit all new headers for the new chain. Therefore the subscription ...
Only top voted, non community-wiki answers of a minimum length are eligible
