42/LOGOS-REPUTATION-INKINGUT #524
Conversation
|
Was "Easye/reputation rfc/20220804a" |
I'll take that number…
| - Providing a mechanism for bootstrapping networks, with a low | ||
| number of nodes. | ||
|
|
||
| # Theory |
There was a problem hiding this comment.
How does this differ from Eigentrust at a high level in terms of properties?
|
|
||
| ## Ikingut Algorithm | ||
|
|
||
| A deceptively simple algorithm for computing reputation of a other |
There was a problem hiding this comment.
| A deceptively simple algorithm for computing reputation of a other | |
| A deceptively simple algorithm for computing reputation of other |
| from a single source of information: *how many correct responses did a | ||
| node give to queries*. The challenge in this metric is the definition | ||
| of *correct response*. We define a correct response as the decision | ||
| the node achieves on the bit value (by means of Glacier). |
There was a problem hiding this comment.
I'd link the Glacier RFC here.
... this sounds like it contradicts the independence of the reputation layer from Glacier.
Maybe:
As an example: when using Ikingut with Glacier, we define [...]
There was a problem hiding this comment.
(Maybe I misread the above and it is not meant to be used outside of Glacier?)
Line 65-66 say it is generic. So my comment above applies.
| of *correct response*. We define a correct response as the decision | ||
| the node achieves on the bit value (by means of Glacier). | ||
|
|
||
| This in essence summarizes the algorithm. There are implementation |
There was a problem hiding this comment.
implementation details should not be in the RFC anyways.
Maybe just: "details and parameters"
| of *correct response*. We define a correct response as the decision | ||
| the node achieves on the bit value (by means of Glacier). | ||
|
|
||
| This in essence summarizes the algorithm. There are implementation |
There was a problem hiding this comment.
This in essence summarizes the algorithm.
Imo, a summary would require a more context on
We define a correct response as the decision the node achieves on the bit value
How do you evaluate the decision a node achieves?
(Also: does node refer to the responding node or the evaluating node?)
| - Adaptive. It processes network and behavior changes fast. | ||
| - Dynamic. It introduces new nodes consistently and fairly. | ||
| - It is robust against strategic adversaries. We will see these in more detail below. | ||
| - No transitive trust. This avoids collusion, greatly simplifies. The |
There was a problem hiding this comment.
What does it simplify greatly?
| - Dynamic. It introduces new nodes consistently and fairly. | ||
| - It is robust against strategic adversaries. We will see these in more detail below. | ||
| - No transitive trust. This avoids collusion, greatly simplifies. The | ||
| tradeoff is more time to build the reputation list. |
There was a problem hiding this comment.
tradeoff with respect to what?
|
|
||
| Incomplete. No publically known implementations. | ||
|
|
||
| # Sovereignty Considerations |
There was a problem hiding this comment.
Imo, we should stick to the naming "Security Considerations", to be consistent with respect to other RFCs.
|
@easye I see no activity in this PR for last 3 weeks with several outstanding comments. What's going on? |
|
@corpetty What would we need to publish this as a raw RFC? Is there anything to add / overhaul contentwise, apart from the few unaddressed comments? |
|
|
||
| # Abstract | ||
|
|
||
| We present Ikingut: an algorithm for purely local computation of peer |
There was a problem hiding this comment.
| We present Ikingut: an algorithm for purely local computation of peer | |
| This document specifies Ikingut, an algorithm for purely local computation of peer |
There was a problem hiding this comment.
In case we go with Standards Track.
| title: 42/LOGOS-REPUTATION-INKINGUT | ||
| name: Logos Node Reputation | ||
| status: raw | ||
| category: Informational |
There was a problem hiding this comment.
If this actually specifies the algorithm, it should be a Standards Track RFCs.
| - Reasonable time to bootstrap reputation. With 10.000 nodes and k ~= | ||
| 9 is in the order of 8-10 min. | ||
|
|
||
| ### Algorithm |
There was a problem hiding this comment.
In case we move this Standards Track, this should be a top-level section.
I'd name it # Algorithm Specification to make it explicit that this is the actual spec.
| - Bring the opportunity of building reputation faster. | ||
| - Ensure accumulation of negative scores for misbehaving nodes. | ||
|
|
||
| # Implementation status |
There was a problem hiding this comment.
I'd remove this and not track implementation status in the spec.
|
Continued discussion : vacp2p/rfc-index#10 |
1 similar comment
|
Continued discussion : vacp2p/rfc-index#10 |
A writeup of Inkingut for public consumption. Incomplete.