mirror of https://github.com/logos-co/roadmap.git
Update documentation
This commit is contained in:
parent
ceda496c23
commit
2a68efab13
2
404.html
2
404.html
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
48
linkmap
48
linkmap
|
|
@ -1,29 +1,29 @@
|
|||
/private/notes/custom-Domain/index.{html} /private/notes/custom-Domain/
|
||||
/private/notes/showcase/index.{html} /private/notes/showcase/
|
||||
/roadmap/consensus/candidates/glacier/index.{html} /roadmap/consensus/candidates/glacier/
|
||||
/roadmap/consensus/theory/snow-family/index.{html} /roadmap/consensus/theory/snow-family/
|
||||
/private/notes/troubleshooting/index.{html} /private/notes/troubleshooting/
|
||||
/roadmap/consensus/overview/index.{html} /roadmap/consensus/overview/
|
||||
/roadmap/consensus/theory/overview/index.{html} /roadmap/consensus/theory/overview/
|
||||
/roadmap/virtual-machines/overview/index.{html} /roadmap/virtual-machines/overview/
|
||||
/roles/rust-developer/index.{html} /roles/rust-developer/
|
||||
/private/notes/CJK-+-Latex-Support-%E6%B5%8B%E8%AF%95/index.{html} /private/notes/CJK-+-Latex-Support-%E6%B5%8B%E8%AF%95/
|
||||
/private/notes/preview-changes/index.{html} /private/notes/preview-changes/
|
||||
/roadmap/consensus/development/prototypes/index.{html} /roadmap/consensus/development/prototypes/
|
||||
/private/notes/config/index.{html} /private/notes/config/
|
||||
/private/notes/editing/index.{html} /private/notes/editing/
|
||||
/private/notes/search/index.{html} /private/notes/search/
|
||||
/roadmap/consensus/candidates/logos-bft/FAQ/index.{html} /roadmap/consensus/candidates/logos-bft/FAQ/
|
||||
/index.html /
|
||||
/private/notes/obsidian/index.{html} /private/notes/obsidian/
|
||||
/roadmap/consensus/development/prototypes/index.{html} /roadmap/consensus/development/prototypes/
|
||||
/roles/distributed-systems-researcher/index.{html} /roles/distributed-systems-researcher/
|
||||
/requirements/overview/index.{html} /requirements/overview/
|
||||
/private/notes/callouts/index.{html} /private/notes/callouts/
|
||||
/private/notes/setup/index.{html} /private/notes/setup/
|
||||
/private/notes/updating/index.{html} /private/notes/updating/
|
||||
/private/notes/config/index.{html} /private/notes/config/
|
||||
/private/notes/hosting/index.{html} /private/notes/hosting/
|
||||
/private/notes/philosophy/index.{html} /private/notes/philosophy/
|
||||
/roles/zero-knowledge-research-engineer/index.{html} /roles/zero-knowledge-research-engineer/
|
||||
/private/notes/ignore-notes/index.{html} /private/notes/ignore-notes/
|
||||
/roadmap/consensus/candidates/logos-bft/overview/index.{html} /roadmap/consensus/candidates/logos-bft/overview/
|
||||
/private/notes/custom-Domain/index.{html} /private/notes/custom-Domain/
|
||||
/private/notes/preview-changes/index.{html} /private/notes/preview-changes/
|
||||
/roadmap/consensus/theory/overview/index.{html} /roadmap/consensus/theory/overview/
|
||||
/roles/rust-developer/index.{html} /roles/rust-developer/
|
||||
/roadmap/virtual-machines/overview/index.{html} /roadmap/virtual-machines/overview/
|
||||
/private/notes/hosting/index.{html} /private/notes/hosting/
|
||||
/private/notes/setup/index.{html} /private/notes/setup/
|
||||
/roadmap/consensus/candidates/logos-bft/FAQ/index.{html} /roadmap/consensus/candidates/logos-bft/FAQ/
|
||||
/roadmap/consensus/development/overview/index.{html} /roadmap/consensus/development/overview/
|
||||
/roadmap/consensus/overview/index.{html} /roadmap/consensus/overview/
|
||||
/index.html /
|
||||
/private/notes/showcase/index.{html} /private/notes/showcase/
|
||||
/private/notes/updating/index.{html} /private/notes/updating/
|
||||
/requirements/overview/index.{html} /requirements/overview/
|
||||
/private/notes/CJK-+-Latex-Support-%E6%B5%8B%E8%AF%95/index.{html} /private/notes/CJK-+-Latex-Support-%E6%B5%8B%E8%AF%95/
|
||||
/private/notes/callouts/index.{html} /private/notes/callouts/
|
||||
/private/notes/ignore-notes/index.{html} /private/notes/ignore-notes/
|
||||
/private/notes/obsidian/index.{html} /private/notes/obsidian/
|
||||
/private/notes/troubleshooting/index.{html} /private/notes/troubleshooting/
|
||||
/roadmap/consensus/candidates/glacier/index.{html} /roadmap/consensus/candidates/glacier/
|
||||
/roadmap/consensus/candidates/logos-bft/overview/index.{html} /roadmap/consensus/candidates/logos-bft/overview/
|
||||
/private/notes/philosophy/index.{html} /private/notes/philosophy/
|
||||
/roadmap/consensus/theory/snow-family/index.{html} /roadmap/consensus/theory/snow-family/
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
@ -262,22 +262,26 @@ Oct 26, 2022
|
|||
<summary>Table of Contents</summary>
|
||||
<nav id="TableOfContents">
|
||||
<ol>
|
||||
<li><a href="#how-much-failure-rate-of-erasure-code-transmission-are-we-expecting-basically-what-are-the-ec-coding-parameters-that-we-expect-to-be-sending-such-that-we-have-some-failure-rate-of-transmission-has-that-been-looked-into---dmitriy">How much failure rate of erasure code transmission are we expecting. Basically, what are the EC coding parameters that we expect to be sending such that we have some failure rate of transmission? Has that been looked into? - Dmitriy</a></li>
|
||||
<li><a href="#how-much-data-should-a-given-block-be-are-there-limits-on-this-and-if-so-what-are-they-and-what-do-they-depend-on---dmitriy">How much data should a given block be. Are there limits on this and if so, what are they and what do they depend on? - Dmitriy</a></li>
|
||||
</ol>
|
||||
|
||||
<ol>
|
||||
<li><a href="#who-sends-the-signatures-up-from-a-given-committee-do-that-have-any-leadered-power-within-the-committee---tanguy">Who sends the signatures up from a given committee? Do that have any leadered power within the committee? - Tanguy</a></li>
|
||||
</ol>
|
||||
|
||||
<ol>
|
||||
<li><a href="#what-is-our-expected-minimum-number-of-nodes-within-the-network---dmitriy">What is our expected minimum number of nodes within the network? - Dmitriy</a></li>
|
||||
</ol>
|
||||
|
||||
<ol>
|
||||
<li><a href="#can-we-also-consider-a-flavor-that-adds-attestationattribution-to-misbehaving-nodes-that-will-come-at-a-price-but-there-might-be-a-set-of-use-cases-which-would-like-to-have-lower-performance-with-strong-attribution-not-saying-that-it-must-be-part-of-the-initial-design-but-can-be-think-throughadded-later---marcin">Can we also consider a flavor that adds attestation/attribution to misbehaving nodes? That will come at a price but there might be a set of use cases which would like to have lower performance with strong attribution. Not saying that it must be part of the initial design, but can be think-through/added later. - Marcin</a>
|
||||
<li><a href="#data-distribution">Data Distribution</a>
|
||||
<ol>
|
||||
<li></li>
|
||||
<li><a href="#how-much-failure-rate-of-erasure-code-transmission-are-we-expecting-basically-what-are-the-ec-coding-parameters-that-we-expect-to-be-sending-such-that-we-have-some-failure-rate-of-transmission-has-that-been-looked-into---dmitriy">How much failure rate of erasure code transmission are we expecting. Basically, what are the EC coding parameters that we expect to be sending such that we have some failure rate of transmission? Has that been looked into? - Dmitriy</a></li>
|
||||
<li><a href="#how-much-data-should-a-given-block-be-are-there-limits-on-this-and-if-so-what-are-they-and-what-do-they-depend-on---dmitriy">How much data should a given block be. Are there limits on this and if so, what are they and what do they depend on? - Dmitriy</a></li>
|
||||
</ol>
|
||||
</li>
|
||||
<li><a href="#signature-propagation">Signature Propagation</a>
|
||||
<ol>
|
||||
<li><a href="#who-sends-the-signatures-up-from-a-given-committee-do-that-have-any-leadered-power-within-the-committee---tanguy">Who sends the signatures up from a given committee? Do that have any leadered power within the committee? - Tanguy</a></li>
|
||||
</ol>
|
||||
</li>
|
||||
<li><a href="#network-scale">Network Scale</a>
|
||||
<ol>
|
||||
<li><a href="#what-is-our-expected-minimum-number-of-nodes-within-the-network---dmitriy">What is our expected minimum number of nodes within the network? - Dmitriy</a></li>
|
||||
</ol>
|
||||
</li>
|
||||
<li><a href="#byzantine-behavior">Byzantine Behavior</a>
|
||||
<ol>
|
||||
<li><a href="#can-we-also-consider-a-flavor-that-adds-attestationattribution-to-misbehaving-nodes-that-will-come-at-a-price-but-there-might-be-a-set-of-use-cases-which-would-like-to-have-lower-performance-with-strong-attribution-not-saying-that-it-must-be-part-of-the-initial-design-but-can-be-think-throughadded-later---marcin">Can we also consider a flavor that adds attestation/attribution to misbehaving nodes? That will come at a price but there might be a set of use cases which would like to have lower performance with strong attribution. Not saying that it must be part of the initial design, but can be think-through/added later. - Marcin</a></li>
|
||||
<li><a href="#also-how-do-you-reward-online-validators--punish-offline-ones-if-you-cant-prove-at-the-block-level-that-someone-attested-or-not---tanguy">Also, how do you reward online validators / punish offline ones if you can’t prove at the block level that someone attested or not? - Tanguy</a></li>
|
||||
</ol>
|
||||
</li>
|
||||
</ol>
|
||||
|
|
@ -360,34 +364,34 @@ Oct 26, 2022
|
|||
|
||||
|
||||
|
||||
<a href="#data-distribution"><h1 id="data-distribution"><span class="hanchor" ariaLabel="Anchor"># </span>Data Distribution</h1></a>
|
||||
<a href="#how-much-failure-rate-of-erasure-code-transmission-are-we-expecting-basically-what-are-the-ec-coding-parameters-that-we-expect-to-be-sending-such-that-we-have-some-failure-rate-of-transmission-has-that-been-looked-into---dmitriy"><h2 id="how-much-failure-rate-of-erasure-code-transmission-are-we-expecting-basically-what-are-the-ec-coding-parameters-that-we-expect-to-be-sending-such-that-we-have-some-failure-rate-of-transmission-has-that-been-looked-into---dmitriy"><span class="hanchor" ariaLabel="Anchor"># </span>How much failure rate of erasure code transmission are we expecting. Basically, what are the EC coding parameters that we expect to be sending such that we have some failure rate of transmission? Has that been looked into? - Dmitriy</h2></a>
|
||||
<a href="#data-distribution"><h2 id="data-distribution"><span class="hanchor" ariaLabel="Anchor"># </span>Data Distribution</h2></a>
|
||||
<a href="#how-much-failure-rate-of-erasure-code-transmission-are-we-expecting-basically-what-are-the-ec-coding-parameters-that-we-expect-to-be-sending-such-that-we-have-some-failure-rate-of-transmission-has-that-been-looked-into---dmitriy"><h3 id="how-much-failure-rate-of-erasure-code-transmission-are-we-expecting-basically-what-are-the-ec-coding-parameters-that-we-expect-to-be-sending-such-that-we-have-some-failure-rate-of-transmission-has-that-been-looked-into---dmitriy"><span class="hanchor" ariaLabel="Anchor"># </span>How much failure rate of erasure code transmission are we expecting. Basically, what are the EC coding parameters that we expect to be sending such that we have some failure rate of transmission? Has that been looked into? - Dmitriy</h3></a>
|
||||
<blockquote>
|
||||
<p><code>Moh:</code> This is a great question and it points to the tension between the failure rate vs overhead. We have briefly looked into this (today me and Marcin @madxor discussed such cases), but we haven’t thoroughly analyzed this. In our case, the rate of failure also depends on committee size. We look into $10^{-3}$ to $10^{-6}$ probability of failure. And in this case, the coding overhead can be somewhere between 200%-500% approximately. This means for a committee size of 500 (while expecting receipt of messages from 251 correct nodes), for a failure rate of $10^{-6}$ a single node has to send > 6Mb of data for a 1Mb of actual data. Though 5x overhead is large, it still prevent us from sending/receiving 500 Mb of data in return for a failure probability of 1 proposal out of 1 million. From the protocol perspective, we can address EC failures in multiple ways: a: Since the root committee only forwards the coded chunks only when they have successfully rebuilt the block. This means the root committee can be contacted to download additional coded chunks to decode the block. b: We allow this failure and let the leader be replaced but since there is proof that the failure is due to the reason that a decoder failed to reconstruct the block, therefore, the leader cannot be punished (if we chose to employ punishment in PoS).</p>
|
||||
</blockquote>
|
||||
<a href="#how-much-data-should-a-given-block-be-are-there-limits-on-this-and-if-so-what-are-they-and-what-do-they-depend-on---dmitriy"><h2 id="how-much-data-should-a-given-block-be-are-there-limits-on-this-and-if-so-what-are-they-and-what-do-they-depend-on---dmitriy"><span class="hanchor" ariaLabel="Anchor"># </span>How much data should a given block be. Are there limits on this and if so, what are they and what do they depend on? - Dmitriy</h2></a>
|
||||
<a href="#how-much-data-should-a-given-block-be-are-there-limits-on-this-and-if-so-what-are-they-and-what-do-they-depend-on---dmitriy"><h3 id="how-much-data-should-a-given-block-be-are-there-limits-on-this-and-if-so-what-are-they-and-what-do-they-depend-on---dmitriy"><span class="hanchor" ariaLabel="Anchor"># </span>How much data should a given block be. Are there limits on this and if so, what are they and what do they depend on? - Dmitriy</h3></a>
|
||||
<blockquote>
|
||||
<p><code>Moh:</code> This question can be answered during simulations and experiments over links of different bandwidths and latencies. We will test the protocol performances with different block sizes. As we know increasing the block size results in increased throughput as well as latency. What is the most appropriate block size can be determined once we observe the tradeoff between throughput vs latency.</p>
|
||||
</blockquote>
|
||||
<a href="#signature-propagation"><h1 id="signature-propagation"><span class="hanchor" ariaLabel="Anchor"># </span>Signature Propagation</h1></a>
|
||||
<a href="#who-sends-the-signatures-up-from-a-given-committee-do-that-have-any-leadered-power-within-the-committee---tanguy"><h2 id="who-sends-the-signatures-up-from-a-given-committee-do-that-have-any-leadered-power-within-the-committee---tanguy"><span class="hanchor" ariaLabel="Anchor"># </span>Who sends the signatures up from a given committee? Do that have any leadered power within the committee? - Tanguy</h2></a>
|
||||
<a href="#signature-propagation"><h2 id="signature-propagation"><span class="hanchor" ariaLabel="Anchor"># </span>Signature Propagation</h2></a>
|
||||
<a href="#who-sends-the-signatures-up-from-a-given-committee-do-that-have-any-leadered-power-within-the-committee---tanguy"><h3 id="who-sends-the-signatures-up-from-a-given-committee-do-that-have-any-leadered-power-within-the-committee---tanguy"><span class="hanchor" ariaLabel="Anchor"># </span>Who sends the signatures up from a given committee? Do that have any leadered power within the committee? - Tanguy</h3></a>
|
||||
<blockquote>
|
||||
<p><code>Moh:</code> Each node in a committee multicasts its vote to all members of the parent committee. Since the size of the vote is small the bit complexity will be low. Introducing a leader within each committee will create a single point of failure within each committee. This is why we avoid maintaining a leader within each committee</p>
|
||||
</blockquote>
|
||||
<a href="#network-scale"><h1 id="network-scale"><span class="hanchor" ariaLabel="Anchor"># </span>Network Scale</h1></a>
|
||||
<a href="#what-is-our-expected-minimum-number-of-nodes-within-the-network---dmitriy"><h2 id="what-is-our-expected-minimum-number-of-nodes-within-the-network---dmitriy"><span class="hanchor" ariaLabel="Anchor"># </span>What is our expected minimum number of nodes within the network? - Dmitriy</h2></a>
|
||||
<a href="#network-scale"><h2 id="network-scale"><span class="hanchor" ariaLabel="Anchor"># </span>Network Scale</h2></a>
|
||||
<a href="#what-is-our-expected-minimum-number-of-nodes-within-the-network---dmitriy"><h3 id="what-is-our-expected-minimum-number-of-nodes-within-the-network---dmitriy"><span class="hanchor" ariaLabel="Anchor"># </span>What is our expected minimum number of nodes within the network? - Dmitriy</h3></a>
|
||||
<blockquote>
|
||||
<p>For a small number of nodes we can have just a single committee. But I am not sure how many nodes will join our network</p>
|
||||
</blockquote>
|
||||
<a href="#byzantine-behavior"><h1 id="byzantine-behavior"><span class="hanchor" ariaLabel="Anchor"># </span>Byzantine Behavior</h1></a>
|
||||
<a href="#can-we-also-consider-a-flavor-that-adds-attestationattribution-to-misbehaving-nodes-that-will-come-at-a-price-but-there-might-be-a-set-of-use-cases-which-would-like-to-have-lower-performance-with-strong-attribution-not-saying-that-it-must-be-part-of-the-initial-design-but-can-be-think-throughadded-later---marcin"><h2 id="can-we-also-consider-a-flavor-that-adds-attestationattribution-to-misbehaving-nodes-that-will-come-at-a-price-but-there-might-be-a-set-of-use-cases-which-would-like-to-have-lower-performance-with-strong-attribution-not-saying-that-it-must-be-part-of-the-initial-design-but-can-be-think-throughadded-later---marcin"><span class="hanchor" ariaLabel="Anchor"># </span>Can we also consider a flavor that adds attestation/attribution to misbehaving nodes? That will come at a price but there might be a set of use cases which would like to have lower performance with strong attribution. Not saying that it must be part of the initial design, but can be think-through/added later. - Marcin</h2></a>
|
||||
<a href="#byzantine-behavior"><h2 id="byzantine-behavior"><span class="hanchor" ariaLabel="Anchor"># </span>Byzantine Behavior</h2></a>
|
||||
<a href="#can-we-also-consider-a-flavor-that-adds-attestationattribution-to-misbehaving-nodes-that-will-come-at-a-price-but-there-might-be-a-set-of-use-cases-which-would-like-to-have-lower-performance-with-strong-attribution-not-saying-that-it-must-be-part-of-the-initial-design-but-can-be-think-throughadded-later---marcin"><h3 id="can-we-also-consider-a-flavor-that-adds-attestationattribution-to-misbehaving-nodes-that-will-come-at-a-price-but-there-might-be-a-set-of-use-cases-which-would-like-to-have-lower-performance-with-strong-attribution-not-saying-that-it-must-be-part-of-the-initial-design-but-can-be-think-throughadded-later---marcin"><span class="hanchor" ariaLabel="Anchor"># </span>Can we also consider a flavor that adds attestation/attribution to misbehaving nodes? That will come at a price but there might be a set of use cases which would like to have lower performance with strong attribution. Not saying that it must be part of the initial design, but can be think-through/added later. - Marcin</h3></a>
|
||||
<blockquote>
|
||||
<p><code>Moh:</code> Attestation to misbehaving nodes is part of this protocol. For example, if a node sends an incorrect vote or if a leader proposes an invalid transaction, then this proof will be shared with the network to punish the misbehaving nodes (Though currently this is not part of pseudocode). But it is not possible to reliably prove the attestation of not participation.
|
||||
<code>Marcin:</code> Great, and definitely, we cannot attest that a node was not participating - I was not suggesting that;). But we can also think about extending the attestation for lazy-participants case (if it’s not already part of the protocol).
|
||||
<code>Moh:</code> OK, thanks for the clarification 😁 . Of course we can have this feature to forward the proof of participation of successor committees. In the first version of LogosBFT we had this feature as a sliding window. One could choose the size of the window (in terms of tree levels) for which a node should forward the proof of participation. In the most recent version the size of sliding window is 0. And it is 1 for the root committee. It means root committee members have to forward the proof of participation of their child committee members. Since I was able to prove protocol correctness without forwarding the proofs so we avoid it. But it can be part of the protocol without any significant changes in the protocol
|
||||
<code>Moh:</code> If the proof scheme is efficient ( as the results you presented) in practice and the cost of creating and verifying proofs is not significant then actually adding proofs can be good. But not required.</p>
|
||||
</blockquote>
|
||||
<a href="#also-how-do-you-reward-online-validators--punish-offline-ones-if-you-cant-prove-at-the-block-level-that-someone-attested-or-not---tanguy"><h4 id="also-how-do-you-reward-online-validators--punish-offline-ones-if-you-cant-prove-at-the-block-level-that-someone-attested-or-not---tanguy"><span class="hanchor" ariaLabel="Anchor"># </span>Also, how do you reward online validators / punish offline ones if you can’t prove at the block level that someone attested or not? - Tanguy</h4></a>
|
||||
<a href="#also-how-do-you-reward-online-validators--punish-offline-ones-if-you-cant-prove-at-the-block-level-that-someone-attested-or-not---tanguy"><h3 id="also-how-do-you-reward-online-validators--punish-offline-ones-if-you-cant-prove-at-the-block-level-that-someone-attested-or-not---tanguy"><span class="hanchor" ariaLabel="Anchor"># </span>Also, how do you reward online validators / punish offline ones if you can’t prove at the block level that someone attested or not? - Tanguy</h3></a>
|
||||
<blockquote>
|
||||
<p><code>Moh:</code> This is very tricky and so far no one has done it right (to my knowledge). Current reward mechanism for attestation, favours fast nodes.This means if malicious nodes in the network are fast, they can increase their stake in the network faster than the honest nodes and eventually take control of the network. Or in the case of Ethereum a Byzantine leader can include signature of malicious nodes more frequently in the proof of attestation, hence malicious nodes will be rewarded more frequently. Also let me add that I don’t have definite answer to your question currently, but I think by revising the protocol assumptions, incentive mechanism and using a game theoretical approach this problem can be resolved.
|
||||
An honest node should wait for a specific number of children votes (to make sure everyone is voting on the same proposal) before voting but does not need to provide any cryptographic proof. Though we build a threshold signature from root committee members and it’s children but not from the whole tree. As long as enough number of nodes follow the the protocol we should be fine. I am working on protocol proofs. Also I think bugs should be discovered during development and testing phase. Changing protocol to detect potential bug might not be a good practice.</p>
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ Required Roles Lead Developer (filled) "
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ With the high level goals of preserving the right to privacy, mitigating the ris
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ Status is an organization building the tools and infrastructure for the advancem
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ Status is building the tools and infrastructure for the advancement of a secure,
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
10
sitemap.xml
10
sitemap.xml
|
|
@ -11,7 +11,7 @@
|
|||
<loc>https://roadmap.logos.co/categories/</loc>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/tags/consensus/</loc>
|
||||
<lastmod>2022-10-26T16:25:23-04:00</lastmod>
|
||||
<lastmod>2022-10-26T16:29:45-04:00</lastmod>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/roadmap/consensus/development/prototypes/</loc>
|
||||
<lastmod>2022-08-19T15:10:38-04:00</lastmod>
|
||||
|
|
@ -32,7 +32,7 @@
|
|||
<lastmod>2022-10-26T16:15:35-04:00</lastmod>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/roadmap/consensus/candidates/logos-bft/FAQ/</loc>
|
||||
<lastmod>2022-10-26T16:25:23-04:00</lastmod>
|
||||
<lastmod>2022-10-26T16:29:45-04:00</lastmod>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/roadmap/consensus/candidates/glacier/</loc>
|
||||
<lastmod>2022-08-19T15:10:38-04:00</lastmod>
|
||||
|
|
@ -47,7 +47,7 @@
|
|||
<lastmod>2022-10-26T16:15:35-04:00</lastmod>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/tags/LogosBFT/</loc>
|
||||
<lastmod>2022-10-26T16:25:23-04:00</lastmod>
|
||||
<lastmod>2022-10-26T16:29:45-04:00</lastmod>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/roles/distributed-systems-researcher/</loc>
|
||||
<lastmod>2022-08-19T15:10:38-04:00</lastmod>
|
||||
|
|
@ -59,7 +59,7 @@
|
|||
<lastmod>2022-10-26T16:15:35-04:00</lastmod>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/roadmap/</loc>
|
||||
<lastmod>2022-10-26T16:25:23-04:00</lastmod>
|
||||
<lastmod>2022-10-26T16:29:45-04:00</lastmod>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/tags/role/</loc>
|
||||
<lastmod>2022-10-26T16:15:35-04:00</lastmod>
|
||||
|
|
@ -74,7 +74,7 @@
|
|||
<lastmod>2022-10-26T16:15:35-04:00</lastmod>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/tags/</loc>
|
||||
<lastmod>2022-10-26T16:25:23-04:00</lastmod>
|
||||
<lastmod>2022-10-26T16:29:45-04:00</lastmod>
|
||||
</url><url>
|
||||
<loc>https://roadmap.logos.co/roadmap/consensus/theory/snow-family/</loc>
|
||||
<lastmod>2022-08-19T15:10:38-04:00</lastmod>
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
index: data.index,
|
||||
links: data.links,
|
||||
})),
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.920148c608627cec8053c5433d6c1b80.min.json")
|
||||
fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.419a3e348936e0a81337b3003273bd26.min.json")
|
||||
.then(data => data.json()),
|
||||
])
|
||||
.then(([{index, links}, content]) => ({
|
||||
|
|
|
|||
Loading…
Reference in New Issue