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

Panic if a node without PRIVATE_CONFIG set sees a private transaction #300

Closed
marcosio opened this issue Feb 27, 2018 · 2 comments
Closed

Comments

@marcosio
Copy link

marcosio commented Feb 27, 2018

System information

Geth version: 1.7.2-stable

OS & Version: Linux

Branch, Commit Hash or Release: ee498061b5a74bf1f3290139a53840345fa038cb

Expected behaviour

We are using IBFT consensus over Quorum v.2.0.1 and Constellation 0.3.1.

We don't want our validator nodes to start constellation and PRIVATE_CONFIG isn't defined because we want them to be specialized in running the consensus algorithm.

When a regular node starts a private transaction the validator node must mine the block.

Actual behaviour

When a regular node starts a private transaction, the validator node raises a runtime error and terminates.

Steps to reproduce the behaviour

Don't start constellation with Geth in one node and send a private transaction.

Backtrace

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x57a9cf]

goroutine 53 [running]:
panic(0xefb180, 0xc420012090)
	/usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/ethereum/go-ethereum/core.(*StateTransition).TransitionDb(0xc433585570, 0x1936460, 0xc42754c060, 0xc4336cf4c0, 0xc433585570, 0x1012320, 0xc42754c060, 0xc45c9d2820, 0x1012320)
	/home/ubuntu/alastria-node/scripts/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/state_transition.go:235 +0xe2f
github.com/ethereum/go-ethereum/core.ApplyMessage(0xc42ebf9000, 0x1936460, 0xc42754c060, 0xc4336cf4c0, 0xc42754c060, 0x52c8067c, 0xc42754e020, 0x74c44c9449c37db8, 0x178a7a62de5d7774, 0x3245c91f, ...)
	/home/ubuntu/alastria-node/scripts/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/state_transition.go:138 +0x5b
github.com/ethereum/go-ethereum/core.ApplyTransaction(0xc42025a480, 0xc420223000, 0xc45c9d52b8, 0xc4336cf4c0, 0xc42f3480f0, 0xc42f3481e0, 0xc42f346b40, 0xc42ad46630, 0xc4300fb980, 0x0, ...)
	/home/ubuntu/alastria-node/scripts/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/core/state_processor.go:121 +0x571
github.com/ethereum/go-ethereum/miner.(*Work).commitTransaction(0xc42a931800, 0xc42ad46630, 0xc420223000, 0x74c44c9449c37db8, 0x178a7a62de5d7774, 0x3245c91f, 0xc4336cf4c0, 0x0, 0xc4201d6c70, 0x0, ...)
	/home/ubuntu/alastria-node/scripts/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/worker.go:604 +0x1d5
github.com/ethereum/go-ethereum/miner.(*Work).commitTransactions(0xc42a931800, 0xc42040fa70, 0xc45b254600, 0xc420223000, 0x74c44c9449c37db8, 0x178a7a62de5d7774, 0x3245c91f)
	/home/ubuntu/alastria-node/scripts/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/worker.go:549 +0x2c7
github.com/ethereum/go-ethereum/miner.(*worker).commitNewWork(0xc420296dc0)
	/home/ubuntu/alastria-node/scripts/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/worker.go:470 +0x9cb
github.com/ethereum/go-ethereum/miner.(*worker).update(0xc420296dc0)
	/home/ubuntu/alastria-node/scripts/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/worker.go:260 +0x232
created by github.com/ethereum/go-ethereum/miner.newWorker
	/home/ubuntu/alastria-node/scripts/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/worker.go:159 +0x5ea

Solution proposed

We make a fork of quorum repository and change core/state_transition.go verifying if private.P is nil.

		if private.P != nil {
			data, err = private.P.Receive(st.data)
		} else {
			err = errConstellationIsntInit
		}
@markya0616
Copy link
Contributor

markya0616 commented Feb 28, 2018

I don't think it's an IBFT issue. It's a general issue about private transactions. @patrickmn Any thoughts?

@patrickmn
Copy link
Contributor

Right, this is not a consensus issue. Quorum expects to have a Constellation node configured if it sees private transactions because it needs to check with that Constellation node to ensure it's not a recipient. This is mostly to avoid a scenario where somebody forgets to set PRIVATE_CONFIG , but it doesn't have to be that way.

@marcossanlab What if we added PRIVATE_CONFIG=ignore or similar to indicate that you explicitly want to ignore private transactions?

@patrickmn patrickmn changed the title IBFT - Panic if validator don't configure constellation Panic if a node without PRIVATE_CONFIG set sees a private transaction Feb 28, 2018
fixanoid pushed a commit that referenced this issue Aug 3, 2018
Added through a PRIVACY_CONFIG-ignore keyword, as described in #300
@fixanoid fixanoid closed this as completed Aug 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants