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

Update to go-ethereum 1.8.1 #702

Merged
merged 9 commits into from
Feb 27, 2018
Merged

Update to go-ethereum 1.8.1 #702

merged 9 commits into from
Feb 27, 2018

Conversation

pedropombeiro
Copy link
Contributor

@pedropombeiro pedropombeiro commented Feb 23, 2018

This PR updates our vendored geth to 1.8.1, while making sure that any updates to whisper v6 in upstream are reverted to v5.

This involved:

  • Deleting 0011-geth-17-whisperv6-70fbc87.patch, since v6 no longer needs patching
  • Remove DNS rebinding protection for localhost, so that e2e tests pass
  • Address type and method signature changes
  • Add patch to downgrade usage of Whisper v6 to v5 in some geth 1.8.1 vendor files
  • Add patches required for cross-compiled builds starting with geth 1.8.0.

Changes of interest in 1.8.1:

  • Geth now writes less state to disk, slowing down datadir growth (#15857)
  • The RPC server now protects against DNS rebinding attacks (#15962)
  • The experimental peer discovery v5 protocol has changed, breaking backwards compatibility with previous releases. Geth 1.8 will not discover LES servers running geth 1.7.
  • Several bugs around CHT handling are resolved (#15692, #16039)
  • Light client peer count is now properly limited (#16010)
  • Whisper protocol v6 as described in EIP-627 is implemented (#15666, #15701, #15802, #15578, #15631, #16046)
  • Discovery v4 and the experimental discovery v5 protocol now run on the same UDP port (#15200)
  • Several issues in the experimental discovery v5 protocol are resolved (#15995, #16036)
  • The GasLimit and GasUsed fields of blocks and transactions have type uint64 instead of *big.Int. This is a breaking API change. (#15466)

Closes #665

@mandrigin
Copy link
Contributor

@pombeirp what about other geth-17* patches? They need to be removed as well...

@pedropombeiro
Copy link
Contributor Author

pedropombeiro commented Feb 23, 2018

@mandrigin you're right, I was so focused on making the transition to 1.8.1 work well that in the end I overlooked removing the 1.7 patches. But I'm not sure that the one 1.7-only patch can be removed. If you see the differences, the behavior upstream is not the same as in our patch:

image

So maybe I need to rename this patch to 0010-geth-18-fix-npe-in-filter-system.patch?

@mandrigin
Copy link
Contributor

@pombeirp hmm that's weird, I'm a pretty much sure I saw that fixed on master... I'll double check.

if args.Input == nil && args.Data == nil {
// If neither Input nor Data were initialized, let's pass an empty slice in Input
emptyByteArray := hexutil.Bytes(make([]byte, 0))
args.Input = &emptyByteArray
Copy link
Contributor

Choose a reason for hiding this comment

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

If Input is a pointer why can't it be nil?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@adambabik the changes to the SendTxArgs struct were based on the fact that is looked like a clone of the one in vendor/github.com/ethereum/go-ethereum/internal/ethapi/api.go, so I assumed we wanted to keep them in sync (even the comments in our struct are identical). If we have the freedom over our own struct, we should have a comment on it that clarifies that. I'll add one for your review.

if err != nil {
return nil
}

return (*hexutil.Big)(parsedValue)
_v := hexutil.Uint64(parsedValue)
Copy link
Contributor

Choose a reason for hiding this comment

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

_v is a bit strange in Go. v := hexutil.Uint64(parsedValue) looks ordinary.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will fix

Nonce *hexutil.Uint64 `json:"nonce"`
// We accept "data" and "input" for backwards-compatibility reasons. "input" is the
// newer name and should be preferred by clients.
Data *hexutil.Bytes `json:"data"`
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to change the data type to *hexutil.Bytes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think so, I was trying to keep it similar to geth's struct. Will change it to Input hexutil.Bytes.

Nonce *hexutil.Uint64 `json:"nonce"`
// We accept "data" and "input" for backwards-compatibility reasons. "input" is the
Copy link
Contributor

Choose a reason for hiding this comment

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

It's our internal struct, so maybe we can remove all Data field and fix all occurrences in this PR?

@@ -143,6 +144,11 @@ func Fatalf(reason interface{}, args ...interface{}) {

// CreateTransaction returns a transaction object.
func CreateTransaction(ctx context.Context, args SendTxArgs) *QueuedTx {
if args.Input == nil && args.Data == 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 don't get why we need this condition.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was more of a sanity check during the migration that slipped through.

input = args.Data
}
if input == nil {
return hash, errors.New("Missing Input/Data byte array")
Copy link
Contributor

Choose a reason for hiding this comment

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

That should be totally fine. Do you get an error if data passed to tx := types.NewTransaction(nonce, toAddr, value, gas, gasPrice, data) is nil?

@adambabik
Copy link
Contributor

@pombeirp Overall it looks good. I am not really sure about these changes to SendTxArgs. It's our struct and we have full control over it so we can clean it immediately without having two fields to store data/input. Also, it looks like it may be beneficial to change its Gas field type to non-pointer.

@pedropombeiro
Copy link
Contributor Author

pedropombeiro commented Feb 26, 2018

@adambabik thanks for the review so far. Regarding Gas, what you're suggesting is to use 0 in cases where nil was being used (e.g. RPCCall.ParseGas)?

pedropombeiro pushed a commit that referenced this pull request Feb 26, 2018
pedropombeiro pushed a commit that referenced this pull request Feb 26, 2018
pedropombeiro pushed a commit that referenced this pull request Feb 26, 2018
pedropombeiro pushed a commit that referenced this pull request Feb 26, 2018
pedropombeiro pushed a commit that referenced this pull request Feb 26, 2018
pedropombeiro pushed a commit that referenced this pull request Feb 26, 2018
pedropombeiro pushed a commit that referenced this pull request Feb 26, 2018
@pedropombeiro
Copy link
Contributor Author

Adding missing tests on bloom filter logic.

Copy link
Contributor

@adambabik adambabik left a comment

Choose a reason for hiding this comment

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

Much cleaner 👏 LGTM

Copy link
Contributor

@mandrigin mandrigin left a comment

Choose a reason for hiding this comment

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

👍 huge job! just a few questions...

@@ -94,23 +94,23 @@ func (r RPCCall) ParseValue() *hexutil.Big {

// ParseGas returns the hex big associated with the call.
// nolint: dupl
func (r RPCCall) ParseGas() *hexutil.Big {
func (r RPCCall) ParseGas() hexutil.Uint64 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it make any sense to actually return also an error here, what do you think?

@@ -84,8 +84,8 @@ func toCallArg(msg ethereum.CallMsg) interface{} {
if msg.Value != nil {
arg["value"] = (*hexutil.Big)(msg.Value)
}
if msg.Gas != nil {
arg["gas"] = (*hexutil.Big)(msg.Gas)
if msg.Gas != 0 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is 0 for sure an invalid value for Gas?
Before the logic assumed that there are 3 types of values: non-set (nil), set, but 0, set, != 0.
Here we lost one state.

Copy link
Contributor

Choose a reason for hiding this comment

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

if so I'd extracted it to a constant to simplify changes in the future

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hence my question above (#702 (comment)). I'm not against keeping the old version that uses nil, tbh.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted the changes to Gas type. I don't think that we gain much by doing that.

}
} else {
gas = uint64(args.Gas)
Copy link
Contributor

Choose a reason for hiding this comment

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

what if gas set here is < defaultGas?

- [`0014-whisperv6-notifications.patch`](./0014-whisperv6-notifications.patch) — adds Whisper v6 notifications (need to be reviewed and documented)
- [`0015-whisperv6-envelopes-tracing.patch`](./0015-whisperv6-envelopes-tracing.patch) — adds Whisper v6 envelope tracing (need to be reviewed and documented)
- [`0017-geth-18-downgrade-to-whisperv5.patch`](./0017-geth-18-downgrade-to-whisperv5.patch) — some files in geth 1.8 import Whisper v6, instead of v5. This patch ensures v5 is used everywhere
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we also have a word here about the xgo patches?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Did you see the README.md file in the geth-xgo folder? Or are you just saying we should add a mention here to that folder?

Copy link
Contributor

Choose a reason for hiding this comment

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

ah, missed that file. it's fine then.

Copy link
Contributor

@mandrigin mandrigin left a comment

Choose a reason for hiding this comment

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

⭐️

@pedropombeiro pedropombeiro merged commit e4cbce1 into develop Feb 27, 2018
@adambabik adambabik deleted the feature/geth-1.8.1 branch December 27, 2019 10:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Investigate/perform upgrade to Geth 1.8.1
4 participants