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

Lack of determinism in programs #4802

Closed
sagar-solana opened this issue Jun 24, 2019 · 8 comments

Comments

@sagar-solana
Copy link
Contributor

commented Jun 24, 2019

Problem

Our BPF loader does not enforce determinism in the programs/instructions they support.

Proposed Solution

Find a way to ensure determinism in our programs...

Tag: @aeyakovenko @garious @jackcmay

@sagar-solana sagar-solana added this to the The Future! milestone Jun 24, 2019

@aeyakovenko

This comment has been minimized.

Copy link
Member

commented Jun 24, 2019

@sagar-solana bpf enforces it.

@sagar-solana

This comment has been minimized.

Copy link
Contributor Author

commented Jun 24, 2019

@jackcmay suggested that it does not yet enforce that entirely.

@garious

This comment has been minimized.

Copy link
Member

commented Jun 24, 2019

The runtime does enforce determinism, but under the assumption that the native program implementing a loader implements determinism. In mainnet, the native programs will be defined at genesis (or introduced via hard fork), so that should be a fine assumption to run with. If the BPF loader doesn't enforce determinism, we have a problem.

@sagar-solana

This comment has been minimized.

Copy link
Contributor Author

commented Jun 24, 2019

Yeah, sorry I think I should have specifically targeted our BPF loader with this issue. The runtime expects determinism and our native programs are allowed an exception(at least until they are moved to BPF) since they get code reviewed ;).

@aeyakovenko

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

@sagar-solana we don't have a case where some validators will throw an exception and others won't, and exceptions do not commit state.

@sagar-solana

This comment has been minimized.

Copy link
Contributor Author

commented Jun 25, 2019

@aeyakovenko this is really more about programs not being deterministic in their execution. Not just exceptions. For example, a program that stores a random number in its account will cause the block it executed within to fail.

Jack mentioned that we've got pointers available within the programs and that any state we generate from those values will not match across the network.

@aeyakovenko

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

@sagar-solana where does it get a random. number? BPF is secure against stake leakage, that's one of the requirements for the Linux kernel as well. The pointer addresses are in the BPF VM, not raw pointers to physical memory.

@sagar-solana

This comment has been minimized.

Copy link
Contributor Author

commented Jun 25, 2019

So I just spoke @mvines about this and I'm reasonably convinced that we don't have an issue here. I was mostly worried about the pointers based on my discussion with @jackcmay but you're right, given that these are within a VM and programs should always be loaded identically the pointers should not vary.

@mvines mvines modified the milestones: The Future!, Waimea v0.17.0 Jun 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.