-
Notifications
You must be signed in to change notification settings - Fork 51
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
Comments
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. |
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. |
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. |
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. |
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? |
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. |
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 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. |
If the network is online but censoring, 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. |
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. |
I can agree that this is bad and should not be allowed. |
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:
Example 1:
go run cmd/server/main.go -redis REDIS_URL -signingKey ETH_PRIVATE_KEY -proxy PROXY_URL -blocklist ~/sanctions.jsonc
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
URIs should be allowed as well as files.
The text was updated successfully, but these errors were encountered: