Comments (5)
I feel like #402 is critical for M2 as well, although I agree with your comment to that issue that it is non-trivial at all.
from mir.
Well, I'd say it is not critical if we accept to be vulnerable to long-range attacks for M2. And personally I'd say it should be acceptable for now.
from mir.
Are you sure the only vulnerability of the way we currently handle non-verified stable checkpoints is that? It seems to me like we just restore the state if we receive a checkpoint far ahead enough in the future, and is precisely those that we may not be able to verify (and in the current believe we just "believe").
If we just dropped anything that is far ahead enough but that we cannot verify then we would risk being to available. But unless I am missing something, it seems too easy for the adversary to break safety in the aforementioned way, so assuming some level of synchrony is a far more reasonable assumption.
from mir.
Not quite sure I understand what you mean. To answer your question, I'm not sure about that being the only potential vulnerability. But regarding the verification of checkpoints we restore our state from, until external membership verification is implemented, we fundamentally face a safety vs. liveness dilemma. If we get a checkpoint far ahead in the future (we currently restore state from any checkpoint from the future, btw.), currently we choose liveness over safety - we just "believe" the checkpoint. If we didn't believe it, we risk loosing liveness if the checkpoint is genuine (everybody already garbage-collected their state we are in and the checkpoint is our only way to catch up).
Of course this is a severe problem and I'd like to have it fixed ASAP, ideally before M2. Let's see what can be done after we fix the other issues that are equally critical.
from mir.
What I mean is whether the adversary sending a fake checkpoint for any time far enough in the future, assuming the recipient just believes it, can, even if liveness is guaranteed, cause undefined behavior of the recipient. This is because the recipient has already assumed the checkpoint he received in the past as valid and prepped state for the future according to it.
If the above scenario is not possible in synchrony, then I agree with you that this is not M2 critical. Otherwise, this is an important consideration that goes beyond liveness vs. safety.
from mir.
Related Issues (20)
- Make factory modules automatically tolerate concurrent application events HOT 1
- Separate transport module and logic
- Eliminate unnecessary sender field used in the transport module
- Declare generated code as such
- Write a high-level description of Trantor HOT 1
- Change membership info to use network protocol as a fallback
- Inefficient slice lookup
- Define constraints on membership weights
- Rename Trantor events to be consistent with protocol description
- Breaking changes in crypto library (G1 curve problem) HOT 1
- Checkpoint typo did not trigger FAILed tests, why? HOT 3
- Serializing empty slices in protobufs
- Conversion of checkpoints in iss.go HOT 1
- Expose basic notion of wall clock time in Trantor
- Transactions getting lost between multisig collector and ISS HOT 1
- Optimize batch reconstruction in Trantor's availability module
- Epoch-aware orderers
- Remove old ISS terminology from the Trantor implementation
- Use zero `MaxProposeDelay` as a default value for PBFT in Trantor
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mir.