List of ways to simulate p2p networks:
https://shadow.github.io/
http://peersim.sourceforge.net/
http://arxiv.org/ftp/arxiv/papers/1405/1405.0400.pdf
Epitope - protocol to increase speed of large block propaga[...]
Gingeropolous posted this 9 years ago
We generally assume that the speed of the internet will increase as the size of monero blocks increase.
What if this is not the case? What if we get huge blocks before the internet can handle it?
I propose the epitope protocol. Essentially, it broadcasts instructions on how to build a block either alongside of or instead of the block.
Variation 1:
When a transaction is created, a hash of the transaction is created and added to the transaction as a "tag".
When a node finds a block, the node creates an "instruction package", which contains the block header and these transaction tags.
The node transmits the instruction package.
A receiving node can then find the transactions in their txpool.
Variation 2:
A node hashes the transactions in their txpool
(then same as above)
Version 2 probably works the best because it keeps the size of the transaction the smallest, allowing it to propagate faster.
And yes, there is the obvious scenario that a node doesn't have all of the transactions in its txpool, but thats ok. Whatever nodes do have the transactions become new start points potentially well ahead of the actual block.
Light blocks could be useful for I2p block relay, if things are slow for some reason
I guess one key thing is if I understood how data is currently relayed through the network. I.e., if the connectivity between peers is relatively static, that means that particular peer set has the same transaction pool. Thus, there might be minimal gains using ranvier relay (my alternative name for it), unless block sizes are huge and network speed is low.
though, over time, a peer could build statistics on its peer list, and begin to learn which of its peers have good up/down speeds and ping, based on their behavior with normal blocks. So, if a node either finds a block or receives a lightblock, it would send differential data packets based on these stats. Thus, peers in class A (lowest ping, highest down, lowest up) could receive package type A... class B (highest ping, highest down, highest up would get package B (full block + light block).
the nature of package types and how to match them with class types would need some working out.
And if the tag package ends up on a node without the matches, the node just relays the package to its peers.
I guess the thing I never think about is attack vectors. So, perhaps a malicious node transmits a false tag package. What would happen? The receiving node would put together the block and find out that it's invalid. Surely this is similar to if a malicious entity broadcasts crap in the existing framework. The only difference is that only nodes with the match set can judge whether a tag package is crap or not.
And how would one stop the propagation of the tag package? So the me pool would just clear a tag package and stop propagation if the tags are already in the block chain. But that's mainly if the full tag set is in the block chain. What if a tag set candidate has a different set than another tag set candidate? Well again eventually one tag set candidate is going to match what's in a given block, and anything that contains anything in that set will be considered a failed tag package and cleared.
I think you're way overthinking this. Of course this has been thought of before. :)
See: https://www.reddit.com/r/btc/comments/3s9lg5/thin_blocks_a_full_1mb_block_would_drop_to_about/
Apparently performance degrades significantly if your mempool is missing many transactions (possibly even worse than not using it at all), but whether that's a significant hindrance I couldn't say.
of course im overthinking it. thats what I do. Its on paper that I do that. :)
> Apparently performance degrades significantly
performance of a node? Performance of the network? Performance of the implementation?
I think if the monero network exceeds internet capacity, all measures will be taken to squeeze out efficiency. And, IMO, it'd be smart to do this before its necessary, because entrenched interests could try to defend their infrastructure (high bandwidth mining nodes vs. low bandwidth), but this type of thing might not require a hard fork.
I read the reddit thread. This basically trades bandwidth (less data downloaded) for processing time (additional verification by the node).
right, so the question is which bottleneck will be reached first, and I'd argue bandwidth. Upon any kind of massive adoption, we will probably encounter this. I mean blockchain bloat isn't something we hide with monero.
this bitcoin block had 1827 transactions. This single monero block with 1 transaction a mixin of 3 was 11.25 kb. 1827 * 11.25 = 20550 kb = 20 MB.
according to the internet, 20 MB block would take 9 seconds to upload on 1 mbps.
of course I realize that bitcoin has 10 minute blocks and we'll have 2 minute blocks, but you get my point.
To be fair, that transaction is on the higher side of size for sure. It has 35 inputs. It's not an unusually large transaction or anything, but it's not an average sized one either.
Your math isn't quite right either, but never mind that.
For funzies:
That BTC block was ~85% full (assuming max size is 1,024 kB, but no block has ever been that large). Its fees were ~0.30 BTC, while reward was 25 BTC. So at the same rate (maybe not a reasonable assumption), 1.4% of the block reward in fees would be enough to fill the block.
Monero @ 1 minute blocks and same size, would be 102.4 kB each, for a total fee of 1.03 XMR, or ~12.6% of the block reward.
Takeway: no idea (except that Monero's fees as % of subsidy are presently ~1 OOM higher than BTC's)
I shouldn't be a hard fork.
Sorry, I meant block propagation time (as in, it could be worse than not using the scheme at all). It seems to me that the risk of that happening should be able to mitigated though.
from what I gather from the link you sent, current implementations of "light blocks" force a receiving node to initiate requests to obtain transactions that its missing, in order to fill the tag set.
What I was imagining wouldn't involve that - if a light block ended up at a node without the transaction hashes to re-create the block, the light block would just be retransmitted. Its almost like there would be 2 mempools - a transaction pool and a lightblock pool.
So I'm a genius. Monero already takes a hash of the transaction, doesn't it? So this would be eVen easier to implement.