Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consensus/istanbul: Istanbul BFT (EIP650) #14674

Closed
wants to merge 15 commits into from

Conversation

yutelin
Copy link

@yutelin yutelin commented Jun 22, 2017

This PR is the implementation of Istanbul BFT protocol in ethereum/EIPs#650

@fjl fjl changed the title Istanbul Byzantine Fault Tolerance consensus/istanbul: Istanbul Byzantine Fault Tolerance (EIP650) Jun 22, 2017
@fjl fjl changed the title consensus/istanbul: Istanbul Byzantine Fault Tolerance (EIP650) consensus/istanbul: Istanbul BFT (EIP650) Jun 22, 2017
@fjl
Copy link
Contributor

fjl commented Jun 22, 2017

Warning: it will take a while to get this merged ;)

@GitCop
Copy link

GitCop commented Aug 31, 2017

Thank you for your contribution! Your commits seem to not adhere to the repository coding standards

  • Commit: 2620c98

  • Commits must be prefixed with the package(s) they modify

  • Commit: 7e94f76

  • Commits must be prefixed with the package(s) they modify

  • Commit: 3f18431

  • Commits must be prefixed with the package(s) they modify

  • Commit: 687d5ca

  • Commits must be prefixed with the package(s) they modify

  • Commit: edcbde3

  • Commits must be prefixed with the package(s) they modify

  • Commit: bd88b3e

  • Commits must be prefixed with the package(s) they modify

  • Commit: 165e40b

  • Commits must be prefixed with the package(s) they modify

  • Commit: 214c4e1

  • Commits must be prefixed with the package(s) they modify

  • Commit: 6637498

  • Commits must be prefixed with the package(s) they modify

  • Commit: ef7b0fc

  • Commits must be prefixed with the package(s) they modify

  • Commit: 1f7da34

  • Commits must be prefixed with the package(s) they modify

  • Commit: f81f870

  • Commits must be prefixed with the package(s) they modify

  • Commit: 13c4671

  • Commits must be prefixed with the package(s) they modify

  • Commit: 1550260

  • Commits must be prefixed with the package(s) they modify

Please check the contribution guidelines for more details.


This message was auto-generated by https://gitcop.com

@stevenroose
Copy link
Contributor

--istanbul.blockpausetime value Pause time when zero tx in previous block, values should be larger than istanbul.blockperiod (default: 2)
I guess it's a good idea to fail when that is not the case :)

}
}

/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgotten comment?

@kesar
Copy link

kesar commented Dec 14, 2017

could conflicts be solved? I would love to use this algo!

@stevenroose
Copy link
Contributor

-- repost of comment on EIP 650 --

The current implementation (as found in Quorum) breaks the concept of the "pending" block, used in several calls, but most notably in eth_getTransactionCount (PendingNonceAt in ethclient):

In Ethereum, the pending block means the latest confirmed block + all pending transactions the node is aware of. This means that directly after a transaction is sent to the node (through RPC), the transaction count (aka nonce) in the "pending" block is increased. A lot of tools, like abigen in this repo or any other tool where tx signing occurs at the application level instead of in geth, rely on this for making multiple transactions at once. After the first one, the result of eth_getTransactionCount will increase so that a valid second tx can be crafted.

With the current implementation of Istanbul, the definition of the "pending block" seem to be different. When submitting a transaction, the result for eth_getTransactionCount for the sender in the "pending" block does not change. When a new block is confirmed (not containing this tx), it does change however (while the value for "latest" doesn't). Then, on the next block confirmation, the "latest" also changes because the tx is in the confirmed block.

So this seems to mean that the "pending block" definition changed from "latest block + pending txs" to "the block that is currently being voted on". I consider this a bug; if this is done on purpose, it breaks with a lot of existing applications (all users of abigen, f.e.) and should be reconsidered.

I originally reported about this issue in the Quorum repo, but there doesn't seem to be a good place to report bugs in Istanbul other than here.

Protocol() Protocol
}

// Handler should be implemented is the consensus needs to handle and send peer's message
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it "if the consensus" instead of "is the consensus" ?

LastProposal() (Proposal, common.Address)

// HasPropsal checks if the combination of the given hash and height matches any existing blocks
HasPropsal(hash common.Hash, number *big.Int) bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would change it to HasProposal to keep it consistent with the rest

)

const (
// fetcherID is the ID indicates the block is from Istanbul engine
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say "fetcher ID indicates that the block..."


// ----------------------------------------------------------------------------

type backend struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather get rid of the // --------------------- comment line and move the struct before the New function (which would make sense because we use the backend struct in the New function) for clarity/cleanliness.

return nil
}

// Broadcast implements istanbul.Backend.Gossip
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't is Gossip, rather than Broadcast ?

if err == nil {
backlog.Push(msg, toPriority(msg.Code, p.View))
}
// for msgRoundChange, msgPrepare and msgCommit cases
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation problem, or is this expected ?

return nil
}

// ----------------------------------------------------------------------------
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove this comment

}
}

// ----------------------------------------------------------------------------
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Useless comment ?

return ms.messages[addr]
}

// ----------------------------------------------------------------------------
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Useless comment ?

}

// roundState stores the consensus state
type roundState struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move this struct just before the newRoundState function

@kaidiren
Copy link

cool, please go ahead

@adamschmideg
Copy link
Contributor

We don't have the capacity to merge and maintain it. We had an informal chat with Quorum, and they might write the integration.

@osouza-de
Copy link

Is there any update regarding the integration?

@jpmsam
Copy link

jpmsam commented Feb 18, 2019

It is integrated in Quorum which is a fork of Geth.

@osouza-de
Copy link

osouza-de commented Feb 18, 2019

It is integrated in Quorum which is a fork of Geth.

Yes, I'm aware of it.
But I mean when it's going to be merged into Ethereum geth official repository.

As we can see in the comment:

We don't have the capacity to merge and maintain it. We had an informal chat with Quorum, and they might write the integration.

}

for _, seal := range committedSeals {
if len(seal) != types.IstanbulExtraSeal {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could someone tell me what this checks? I was trying to figure out where we check during the commit/finalization that the commit seals are valid?

@stale
Copy link

stale bot commented Mar 1, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@itsdevbear
Copy link
Contributor

wen merge >:(

@karalabe
Copy link
Member

karalabe commented Dec 2, 2021

never

@zhiqiangxu
Copy link
Contributor

never

@karalabe Is there an official reason for this?

@sarthaktNt
Copy link

Polygon Edge migration from POA to POS

I have created a 4 nodes POA network using polygon-edge.
As mentioned ,I have tried out the approach for migration.

I have deployed the staking smart contract in block no 59357 .All the validators staking has staked before block no 59750.I have verified the list in staking contract.
I have restarted all the nodes after migration to rebuild the blocks from new genesis.json.
polygon-edge ibft switch --chain ./genesis.json --type PoS --deployment 59357 --from 59750
But the blocks are not getting generated from 59750 due to the following error.

failed to get validators when calculation quorum

Please guys help me to resolve my issue

@karalabe
Copy link
Member

This is a repo for Ethereum, not Polygon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet