Add Documentation #41
Conversation
|
I'll have a solid read through this tomorrow. I'd recommend wrapping the longer paragraphs to keep a relatively consistent line length. I typically use the Rewrap extension for VSCode with the default settings ( |
JCSanPedro
force-pushed
the
spec_docs
branch
4 times, most recently
from
6e2a800
to
a6c00e7
Compare
|
|
||
| #### **faceValue** | ||
|
|
||
| The value in `SOLO` of a winning ticket. |
There was a problem hiding this comment.
Might be good to define SOLO somewhere, since it's not a widely used term. I think just saying SYLO/SOLO is equivalent to ETH/WEI would be enough.
|
|
||
| In general, Bob also cannot be trusted to unlock Alice’s payment for Bob's node. | ||
| Because Alice is sending to Bob, Bob and Alice may have some relationship with | ||
| one another, and so Bob is assumed to have some incentive to refuse to unlock |
There was a problem hiding this comment.
Would it be possible for a malicious third party to cut Bob's ability to confirm some messages have been received? I.e. Firewall allowing Bob to receive messages but not confirm them.
Possible mitigation: could the protocol hide information about sending party till delivery confirmation? I.e. Bob must confirm receipt of a message before being able to unlock information about the sender?
There was a problem hiding this comment.
Good question. In general, everything is encrypted (using Bob's public key). In the case of sender information, it would be encrypted by libp2p's p2p encryption mechanism (sort of like TLS). So the malicious third party would need access to the private key to do anything.
There was a problem hiding this comment.
Libp2p streams are bidirectional, so you can't send Bob a message and then have him unable to respond. Connections are made by the receiver (like push notification services), so if Bob can't connect to his node, he needs to pick a different one (a feature that will be available when we have users on the network).
| again, which takes time for the escrow to unlock, and has an associated gas | ||
| cost. This gas cost puts an effective price on the “free” relay obtainable this | ||
| way, and makes the strategy of repeatedly spinning up new sending peers worse | ||
| than just paying for relay in the first place. |
There was a problem hiding this comment.
Is it possible to do a premeditated multi wallet attack?
Escrow is sent to a reasonable number of wallets beforehand, say ~100-100000, 3 months before attack, at the best gas price possible. Thereby mitigating escrow unlock time (to an extent).
Ideally, would be better if senders whom do not have much recent-activity be trusted less? In addition to having escrow unlock times - but perhaps reducing the time it takes to unlock.
There was a problem hiding this comment.
I'm not sure about this. My intuition tells me that kind is still too expensive to be worth it.
@JoshD641 would have a better idea though.
There was a problem hiding this comment.
"Escrow is sent to a reasonable number of wallets beforehand, say ~100-100000, 3 months before attack, at the best gas price possible. Thereby mitigating escrow unlock time (to an extent)."
You can start sending messages immediately once escrow is deposited - it's just that there's a delay between calling unlock() and the actual withdrawal of funds back to your wallet. The locked escrow has no Return On Investment, and can't be used for anything at all (even sending new messages) while it's unlocking, so there's a small opportunity cost associated with those funds being locked away for that time (compared to, say, putting that capital into a yield farm contract and earning 5% - those potential earnings are lost).
The more important cost is the gas associated with the token transfer from wallet to escrow, and then from escrow to wallet again to recover the funds. This gas cost scales linearly with the number of wallets (2 txns per wallet), which means that so long as the value of the relay "stolen" by one sender A is less than 2x the transaction gas cost, it doesn't make sense to do this attack. That limit is easy enough for a node to calculate, and the nodes can set their tolerances for non-delivery before they start blacklisting accordingly - though that isn't implemented yet on the node side.
In general you can't really measure the recent activity of a sender from a node in a reliable way. Node A doesn't know how many messages have been sent to the other nodes by this sender, and only a tiny fraction of messages result in on-chain evidence (a winning ticket), so you can't refer to that either.
| Delegated Staking. | ||
|
|
||
| Using the total amount staked to Nodes across the Network, the Stake Directory | ||
| is updated each epoch. The Stake Directory is used by the stake-weighted scan |
There was a problem hiding this comment.
A major geographic network event could occur, disintegrating a high-stake-amount-node service for a period of time.
Would be nice to have quality of service metric in the future as well? This may be complex to implement - some sort of consensus algorithm that looks at number of successful receipts per node / weighted by sender reputation, (among other things to prevent cheating) for the last hour.
There was a problem hiding this comment.
Yep you're right.
In the future, there will be an on-chain function that could be used to submit cryptographic evidence of work based on the amount of stake the Node has. That will then be used to determine if Nodes are performing as expected. It's not needed for phase 2 of the Sylo Network, so isn't implemented in the contracts or included in the spec, but there is a plan for it.
There was a problem hiding this comment.
If you'd like to look into about our ideas for how that might work, you can have a read here: https://app.gitbook.com/o/-MdydbpBeh4lPp-v7Xwz/s/-Mdyc49lpdv1XGu_u5XS/c/-MeNz7KBWPJ0K5DJS5hi/how/incentivised-event-relay/incentivizing-performance
| ### Delegated staking | ||
|
|
||
| A node can be staked by the Node’s owner, or by other holders of the SYLO token | ||
| - the latter is known as delegated staking. |
There was a problem hiding this comment.
Can a node owner prevent other holders from staking their node? Might be good to clarify this here.
There was a problem hiding this comment.
There will be some restrictions that can be set by the Node, for example, requiring delegated stakers to stake a minimum amount of SYLO. But currently not implemented.
docs/overview.md
Outdated
|
|
||
| The scan function does this using the following steps: | ||
|
|
||
| - Compute the hash of the peer ID, concatenated with the current epoch number |
There was a problem hiding this comment.
Is this the peerID of the node or the peerID of the message recipient/sender?
There was a problem hiding this comment.
PeerId of the recipient. I'll clarify it.
| takes the epoch number as input to it’s hash, each peer’s Sylo Node is | ||
| randomized each epoch. This provides additional security against traffic | ||
| analysis, and ensures that nodes receive work in proportion to their stake over | ||
| the long run, regardless of epoch-by-epoch traffic variation. |
There was a problem hiding this comment.
Is it possible that high stake nodes get too much traffic? (I think yes but small).
Is it possible for a node to report that it is too busy? If so, how does fallback / chain of backup nodes work?
There was a problem hiding this comment.
Is it possible that high stake nodes get too much traffic? (I think yes but small).
Yes it's possible. In phase 3, Nodes will be able to set a maximumDelegatedStake value that will restrict the amount of stake that will be used in the Stake directory. This would prevent the case of a Node suddenly receiving a lot of delegated stake, and then receiving too much traffic.
Is it possible for a node to report that it is too busy? If so, how does fallback / chain of backup nodes work?
The economic incentives should hopefully keep most nodes performing. There is also a section on Channels in the future works part, which briefly discusses how a user could switch nodes.
There was a problem hiding this comment.
Since "percent stake" is relative, the work assigned to a node can change without any input from them (i.e. a bunch of other nodes unstake).
There is really no way to prevent such changes in the network, even with a maximum delegated stake value. Node operators will probably need to build in a safety margin to prevent being at risk of slashing. Ideally we would add features to the nodes to allow for horizontal scaling during times of heavy load, but such features will be down the road a bit.
| we need a way to exchange value for every relay performed, without relying on an | ||
| on-chain transaction each time. | ||
|
|
||
|
|
There was a problem hiding this comment.
Could we please include a overview of messages? Some example of what is being passed between client and sender, and the limitations.
- Message Length Limitation?
- Do longer messages cost more?
- Message Type limitation? Do we allow images/movies/audio? Do they cost more?
- Do we break up messages?
There was a problem hiding this comment.
Good point. Something like that could be included in the spec, or may be we need to write up a more technical spec for the Event Relay protocol itself (the spec included in this repo is more focused on the contracts).
@paul-freeman Do you have any metrics for the events?
There was a problem hiding this comment.
The protocol currently has a message size limit of 2048 bytes (which I took from Firebase or APN, I think). This is for the opaque bytes in the actual event (not including the metadata). Having a limit is important since storage is a significant part of the service. But the actual value we settle on could be changed.
We are really assuming that messages will usually be small events or pointers to larger data on IPFS.
There was a problem hiding this comment.
No description provided.