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

Allow users to choose their own sanctions lists #99

Open
Pandapip1 opened this issue Aug 15, 2022 · 10 comments
Open

Allow users to choose their own sanctions lists #99

Pandapip1 opened this issue Aug 15, 2022 · 10 comments

Comments

@Pandapip1
Copy link

Pandapip1 commented Aug 15, 2022

Summary

I propose that a new command line argument be added that allows users to set the sanctions list of their choosing. The default OFAC sanctions list would be removed.

Proposed usage:

go run cmd/server/main.go -redis REDIS_URL -signingKey ETH_PRIVATE_KEY -proxy PROXY_URL -blocklist BLOCKLIST_PATH_OR_URL

Example 1:

go run cmd/server/main.go -redis REDIS_URL -signingKey ETH_PRIVATE_KEY -proxy PROXY_URL -blocklist ~/sanctions.jsonc
/* filename: sanctions.jsonc */
[
    "0xdead",
    "0x1234",
    "0x0" // You get the point
]

JSON-C was used as an example, but YAML, JSON, or just a newline-separated file could also be acceptable file formats. Do whatever is easiest to develop, as long as this feature is implemented.

Example 2

go run cmd/server/main.go -redis REDIS_URL -signingKey ETH_PRIVATE_KEY -proxy PROXY_URL -blocklist https://someusgovmtwebsite.gov/blocklist.txt

URIs should be allowed as well as files.

@MicahZoltu
Copy link

While I agree this is better than the current situation, I think this is still against the ethos of Ethereum as Ethereum is all about censorship resistance. Software being built for Ethereum should not have censorship as a concept baked into them at all. If someone wants to censor we cannot stop them, but we also shouldn't be making it easy for them.

@Pandapip1
Copy link
Author

Pandapip1 commented Aug 16, 2022

I say make it easy for people to run a validator with confidence that they aren't breaking any laws, strengthening the network for the majority of the participants. Since most sanctions lists disagree with each other, it's equivalent to (maybe at most) tripling the time it takes for a sanctioned transaction to make it into a block, while massively increasing staker confidence and overall security.

I don't disagree that censorship is bad though, and the best case would be that there are no sanctions that need complying with.

@stbrody
Copy link

stbrody commented Aug 16, 2022

Imagine a person is interested in running their own node, rather than rely on a centralized node provider like Infura, because they believe in the value of decentralization. This person has moderate technical ability - enough to operate a command line, modify a config file, etc, but probably not enough to fork the flashbots codebase, modify it, and compile it from scratch. This person happens to live in the US and has no interest in going to federal prison.

Without this PR, this person has no way to run their own node. Without giving users and node operators choice about what types of transactions they choose to interact with on their own node, you cut off a large portion of your potential user base and actually hamper decentralization. Hampering decentralization hampers censorship resistance in the long term.

If all node operators in different regions of the world follow the sanctions list of their own region, then so long as the node operators come from a sufficiently diverse set of regions around the world, and those regions have non-perfectly-overlapping sanctions lists, then nothing actually gets censored at the ethereum base layer.

@bertmiller
Copy link
Member

Without this PR, this person has no way to run their own node.

Sorry @stbrody I think you misunderstand what this repo is. This repository is for the software that Flashbots uses to provide users an rpc endpoint to send their transactions to so that we can protect them from frontrunning. This repository has nothing to do with operating a node or the base layer of Ethereum.

Thanks for the issue @Pandapip1. We're listening and thinking carefully about what to do.

@stbrody
Copy link

stbrody commented Aug 17, 2022

This repository is for the software that Flashbots uses to provide users an rpc endpoint to send their transactions to so that we can protect them from frontrunning.

Thanks for clarifying @bertmiller. Don't the same arguments still apply though? I assume flashbots still benefits from having more operators running their software, in more different regions around the world?

@MicahZoltu
Copy link

MicahZoltu commented Aug 17, 2022

I say make it easy for people to run a validator with confidence that they aren't breaking any laws, strengthening the network for the majority of the participants.

Every validator that is censoring transactions is a validator that is decreasing Ethereum's ability to do the one thing that it is meant to do, which is provide censorship resistance. It is better to have fewer validators that are not censoring than to have more validators where the extras are censoring.

Also, every validator that is added decreases the rewards for all other validators, so by adding a censoring validator we are not only adding a validator that is working against the goals of the network, but we are also disincentivizing other non-censoring validators from participating by a bit.

@Pandapip1
Copy link
Author

Pandapip1 commented Aug 18, 2022

Every validator that is censoring transactions is a validator that is decreasing Ethereum's ability to do the one thing that it is meant to do, which is provide censorship resistance. It is better to have fewer validators that are not censoring than to have more validators where the extras are censoring.

Counterargument: At some point, it's better to have more validators that censor transactions inconsistently than to have less validators that don't censor any transactions.

Proof: Assume we have only one validator that can stake 32 ETH in the entire world due to laws. This is the worst-case scenario but is possible. That one validator is securing the network... until it:

a) Goes down, or
b) A malicious user (or worse, government) runs their own validator with much more ETH (Say, 10000). They now have complete control over the network, and could prevent users from sending transactions to one another in order to accumulate 32 ETH to run their own illegal validator.

Now, what happens if everyone censors using a different list?

Well, as long as less than 33% of the validators decide to censor a single address, nothing. If it's greater than 33% but less than 50%, then my understanding is that finality is unachievable (bad), but that the blocks still exist (not full censorship).

Now, these are two extremes, but the answer is going to depend on how complicit people are going to be, and how stringent the laws are. If it's extremely complicit with stringent laws (what appears to be the case), then this proposal is better. If people collectively decide to break their country's law, then your proposal is better.

@MicahZoltu
Copy link

If the network is online but censoring, then the network is not functioning correctly.
If the network is offline, then the network is not functioning correctly.

I consider both of these situations to be equally bad. The offline situation is more noticeable and more likely to be fixed (assuming someone cares about Ethereum), while the second one is less likely to be noticed and less likely to be fixed, which is why we should take care to prevent it.

@MicahZoltu
Copy link

Well, as long as less than 33% of the validators decide to censor a single address, nothing. If it's greater than 33% but less than 50%, then my understanding is that finality is unachievable (bad), but that the blocks still exist (not full censorship).

As long as there is one honest validator, and the censors are not reorging blocks, then eventually the censorship will stop when an honest block producer produces a block. The situation under which censorship can be permanent is when block producers are refusing to build on top of blocks that don't censor.

@Pandapip1
Copy link
Author

block producers are refusing to build on top of blocks that don't censor

I can agree that this is bad and should not be allowed.

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

No branches or pull requests

4 participants