> as any routing node which self-clones to gain a larger share of routing-work for a given transaction also reduces by half the ability for that transaction to contribute towards the valid block production work threshold
Seems like the primary assumption is that Sybill only happens vertically (one node being taken as multiple), but in reality Sybil is usually a per-actor problem, i.e. a CDN could be by a single actor created to ensure minimal hops thereby creating an effective Sybill attack.
Disclaimer: this is my read of their system it might have different counter-measures/assumptions.
"Until we reach the point we can formally establish that users are incentivized to broadcast their transactions to multiple nodes, we ask readers to treat this assumption as a design parameter as well."
To put it simply, the proof requires behavior by users which is neither incentivised or enforced. Other egregious flaws are that the "proof" insists that sybil actors do things not required of non-sybil actors, i.e. add unnecessary routing hops, and that sybil actors are arbitrarily excluded from being the orgin node.
The solution formally and mathematically achieves these properties:
- not profitable to add routing hops - profitable to share with others - not profitable to share with yourself (!!!)
If you have a single central entity somewhere that isn't a sybil attack. Nothing wrong with being concerned about network centralization, but you're much less likely to have it in sybil-proof systems as above given that nodes suddenly have commercial incentives to share data as opposed to hoarding it.
If so, the response to that is: 'this type of behavior doesn't grant this node an increased ability to influence consensus compared to if they routed all data under the same identity.'
This has led me to understand empathically why there were people suggesting we change bus terminology from master/slave to anything else.
> This has led me to understand empathically why there were people suggesting we change bus terminology from master/slave to anything else.
I guess you haven't been one fixing the fallout that pointless shit caused.
In fact, DID already has a disambiguation page on Wikipedia: https://en.wikipedia.org/wiki/DID_(disambiguation). I don't think Dublin Institute of Design or Data Item Descriptions constitute "a wholesale theft of a language".
However, like many of the peer comments here I feel the overlap of these two domains is vanishingly small. Presumably only yourself and a handful of others would even be aware of the etymology.
As you feel so strongly, perhaps a well-written blog post would rank highly for anyone curious enough to disambiguate.
--
Routing nodes will lose to competitors if another routing path on the same fee is included in a block. They also diminish the 'work' in the transaction (which overcomes the threshold to make blocks) by adding hops - so it's only worth it to add hops in order to 'win the race.' All nodes in the path have an expected value on the fee, but the further into the chain of hops, the more that diminishes.
In a technical sense, it isn't necessary to then reward those routing nodes to keep the anti-Sybil property for the routing network itself, but it does give other nice properties related to trustlessness and network provision.
1. Data pays no fees, routers get no rewards
Assuming data is published to a shared medium which requires some threshold of "work" which stems from the data, then even just the act of including that data into your medium becomes more difficult the more hops it accumulates. You then of course rely on trust assumptions to fight spam.
2. Data pays fees, routers get no rewards
If you use some measure of cost to create data, you can handle spam, and that cost determines how much work the data carries with it and thus how likely it is to be included into the medium (trying to be very general here, but in the linked article that medium is a blockchain). The trust assumptions here rest with the routing nodes 'doing their duty.'
3. Data pays fees, routers get rewards
This is the model Saito has - it removes trust assumptions for users and routers as if one tries to 'scam' the other (either a Sybilling user creating fake data, or a Sybilling router creating fake hops), the native money can be leveraged to create recourse without an authoritative audit or punishment - purely economic.
I'm kinda okay with blockchains always remaining vulnerable and becoming relics of the past. It's all a scam. Not patching it.
I would agree with the assessment, but avoiding it for research would be equally dumb. The tech itself has very interesting properties and potential applications outside of “finance”. It’s just a decentralized and slow global db with an (empirically battletested) consensus mechanism.
In fact there almost as many consensus mechanisms as there are blockchains. In the beginning it was PoW that defined what was a blockchain, but with its obsolescence in favor of Proof of stakes for many chains the situation got muddier. Facebook's Libra/Diem for instance was based on a strongly consistent algorithm (as opposed to the eventually consistent nature of PoS) that's not that different from PBFT and ByzPaxos.
https://github.com/SaitoTech/papers/blob/main/sybil/A_Simple...
It would be difficult to modify POS to have these properties, but the question of how best to accomplish that would be something for developers in those other networks to address.
The essay discusses a method to prevent Sybil attacks, where a single adversary controls multiple nodes on a network to subvert the network's functionality, in blockchain networks by making it unprofitable for malicious nodes to add unnecessary 'hops' in transaction paths. Saito's mechanism rewards nodes for efficiently routing transactions to block producers, thus making Sybil attacks less lucrative. This is further illustrated with mathematical proof and examples comparing honest and Sybil behaviors, highlighting how the expected rewards change in both scenarios .
