No, honest peers can easily ban them for relaying invalid transactions, all the way to the mining level. You don’t want to run the risk of cutting off your route. Also, tx validity can be processed in parallel with the ECDSA sign operation, so I don’t see this as a major practical optimization, though this should be tested. Would love to hear arguments otherwise though.
Not sure I agree. At the end of the day, miners need to get paid by including valid transactions in blocks, so they should absolutely ban peers that open them to a DoS vector.
They may, because they can’t tell if the fee will be paid unless they are holding state. This would open them up to a trivial DoS vector, especially with peer banning.
Full nodes serve as relayers and get paid. Eventually, this role will move to proposers.
This is a way to incentivize full nodes with “proof of resources” in Ethereum. There are other incentivization schemes that will incentivize making blockchain data available (serving downloads to other users who are not storing state). This will of course make downloads cost money. I’ll be proposing such a scheme in the next few days, though some proposals for this already exist.
Making the hop fees variable is a great economic idea, thanks!! I really like that variant of the scheme.
One thing I do want to support is a user selecting a pre-defined longer paths; I suppose they can just pre-sign with the addresses of those hops, so you get the same thing, and they also have more granularity on the incentives there.
Good answers. Then I wonder how the network ends up building routes and what attacks might be there. How does bootstrapping / maintaining peer lists fit into this and is this secure against sybil attacks?
Really interesting work, by the way. This kind of thing is well overdue.
Since payments need to be on-chain, you can likely maintain a bonded peer list on chain too though. But yeah, these interactions are super worth thinking about. Deposits for relayers can guard against Sybil, though there would be a balance there because you don’t want to require a large / frequent deposit; perhaps optional deposits, where the probability of being selected in a node’s peer list was weighted by deposit, plus some classic slots? Sybil can just be viewed as providing infrastructure in this model.
I think a glaring issue with this type of scheme is that in the current PoW architecture how do you know which miner to send a transaction to? By design the miners creating blocks are random, so under this scheme it seems like it would cause extreme mining centralization by rewarding more powerful miners both from the block reward and the fact that other miners don’t get nearly as much traffic to get transactions fees from.
Ideally you’d broadcast to all miners who intend to mine a block. The economies of scale for mining are so bad that I doubt small number of fees could make a difference. If anything, you’d find an intermediary to route to you at a relatively small cut (there would be an implicit competitive marketplace for such intermediaries).
How do you calculate and find all miners “intending to mine a block”? It seems like this would inflate the cost of a transaction and encourage users to just pick a few miners, which then would give those miners extreme censorship control.
That’s up to the user. Naively you can gossip everything, and assume miners will attempt to peer with every node at a height of 1 to collect maximum fees. You can also use a separate relay network, both, etc.
It wouldn’t “inflate the cost of a transaction”, it would bring it closer in line to its true cost to the network (assuming you’re talking about relay fees).
The miner of a block already has full censorship control over that block. If relaying miners censor relays, this will incentivize relayers who do not censor to do their best to get transactions into the blocks of miners who do not censor. In case of extreme censorship, the value of these relays and thus the associated fees will rise in a competitive marketplace, incentivizing paths that route around the censorship.
Think Great Firewall of China; a scheme like this could, even when all p2p traffic / ETH nodes are disabled, incentivize steganographic channels between users submitting traffic and miners including them in blocks.
Actually does quite the opposite of censorship control :).
The miner of a block already has full censorship control over that block. If relaying miners censor relays, this will incentivize relayers who do not censor to do their best to get transactions into the blocks of miners who do not censor. In case of extreme censorship, the value of these relays and thus the associated fees will rise in a competitive marketplace, incentivizing paths that route around the censorship.
So if I understand you correctly, you mean to say that relayers are actually incentivized to send messages to miners who do not censor? This comes from the fact that the relayer isn’t paid unless the transaction is mined right?
It wouldn’t “inflate the cost of a transaction”, it would bring it closer in line to its true cost to the network (assuming you’re talking about relay fees).
I was thinking that miner selection could be an issue if the relayer cost is too high, and users are disincentivized to send transactions to all miners. When the hopfee is an appreciable amount, the cost of sending a transaction to all miners could be something like 100 or 1000 times more than the miner fee. In that scenario I think there is a high risk of users only choosing to send transactions to one miner. I suppose this could be seen as intended behavior, but I don’t know what order the hopfee would end up being if we want to keep all miners seeing all broadcast transactions, which seems like an important property to have.
You only pay the hopfee once. EG if your hopfee is 1ETH and you have at most 10 hops, the most fees you will ever pay is 10ETH, no matter how many nodes you relay too. Only the winning route (aka the route that actually gets a transaction mined) is compensated, not all routes. So in fact all users and relayers will gossip as widely as possible to maximize the probability that their path is the winning one, and they get paid.
You only pay the hopfee once. EG if your hopfee is 1ETH and you have at most 10 hops, the most fees you will ever pay is 10ETH, no matter how many nodes you relay too. Only the winning route (aka the route that actually gets a transaction mined) is compensated, not all routes. So in fact all users and relayers will gossip as widely as possible to maximize the probability that their path is the winning one, and they get paid.
Is the A_i that each relayer adds to the transaction bundle and signs the address at which they wish to be paid their hop fee? I initially understood the hop fee payments to be made to the PK_1, ..., PK_n keys, which was somewhat confusing.
In steady state, the protocol optimizes the multicast tree in two ways. Whenever a message is received via both an eager link and a lazy message summary, its hop count is compared. When the eager transmission hop count exceeds the lazy hop count by some threshold, then the lazy link can replace the eager link as a tree edge, reducing latency as measured in hops. In addition, active peers may be periodically replaced by passive peers with better network proximity, thus reducing propagation latency in time.—https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md
This is without any incentivization.
However, this very optimization may also be a concern for randomness and security, as it may be more vulnerable to attacks via peers that are close in proximity. However, this is beyond the scope of this topic so we should move discussion on this elsewhere, e.g. https://github.com/libp2p/go-floodsub/issues/77 or https://github.com/libp2p/libp2p./issues/33 (I’ve chosen the former).
See also https://www.pokt.network/. At the moment I am leery of a particular, but important, aspect of their planned design, which is using federated nodes that have a high stake, although they do not participate in blockchain consensus, only relay validation. However, I think you can use a committee to validate or attest to the validity of relays, as is planned with eth2.
Instead of doing normal transfers we can use probabilistic payments where probability p = amount / ( # of hops + fixed miner reward). In order to maximise p relayers will forward msg ASAP with shortest / fastest path. everyone in the p2p network will maintain DHT to decide the shortest / fastest path.