Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements to conference paper #31

Closed
sbellem opened this issue Aug 23, 2017 · 10 comments
Closed

Improvements to conference paper #31

sbellem opened this issue Aug 23, 2017 · 10 comments

Comments

@sbellem
Copy link
Contributor

sbellem commented Aug 23, 2017

The purpose of this issue is to communicate small improvements (such as typos) to the research paper by Miller et al. The Honey Badger of BFT Protocols.

@sbellem
Copy link
Contributor Author

sbellem commented Aug 23, 2017

small typos

4.4 Instantiating ACS Efficiently

(page 7, last paragraph before subsubsection Communication-optimal reliable broadcast)

We now briefly explain the RBC and ABA constructions before explaing the Ben-Or protocol in more detail.

"explaing" --> "explaining"

Communication-optimal reliable broadcast

(page 7, last paragraph of subsubsection Communication-optimal reliable broadcast)

If the sender is correct, the total running time is three (asynchronous) rounds; and in any case, at most two rounds elapse between when the first correct node outputs a value and the last outputs a value. The reliable broadcast algorithm shown in Figure 2.

"is" seems to be missing

The reliable broadcast algorithm is shown in Figure 2.

@sbellem
Copy link
Contributor Author

sbellem commented Aug 23, 2017

wondering ...

1.1 Our Contributions

Timing assumptions considered harmful.

[...]

on page 2, first paragraph

Second, even when the weak synchrony assumptions are satisfied in practice, weakly synchronous protocols degrade significantly in throughput when the underlying network is unpredictable. Ideally, we would like a protocol whose throughput closely tracks the network’s performance even under rapidly changing network conditions. Unfortunately, weakly asynchronous protocols require timeout parameters that are finicky to tune, especially in cryptocurrency application settings; and when the chosen timeout values are either too long or too short, throughput can be hampered. As a concrete example, we show that even when the weak synchrony assumptions are satisfied, such protocols are slow to recover from transient network partitions (Section 3).

"weakly asynchronous" --> "weakly synchronous" (?)

@sbellem
Copy link
Contributor Author

sbellem commented Aug 25, 2017

wondering ...

C. ASYNCHRONOUS BINARY BYZANTINE AGREEMENT

Realizing binary agreement from a common coin.

[...]
We instantiate this primitive with a protocol based on cryptographic common coin, which essentially act as synchronizing gadgets.

"on cryptographic common coin" --> "on cryptographic common coins" (?)

@sbellem
Copy link
Contributor Author

sbellem commented Aug 25, 2017

7. Reference

ref [42]:

A. Mostefaoui, H. Moumen, and M. Raynal. Signature-free asynchronous byzantine consensus with t< n/3 and o (n 2) messages. In Proceedings of the 2014 ACM symposium on Principles of distributed computing, pages 2–9. ACM, 2014.

o (n 2) --> O (n^2)

@sbellem
Copy link
Contributor Author

sbellem commented Oct 16, 2017

3. THE GAP BETWEEN ASYNCHRONOUS AND WEAKLY SYNCHRONOUS NETWORK MODELS

In this section, we present make two counter arguments that refute the premise above.

present or make ?

@sbellem
Copy link
Contributor Author

sbellem commented Oct 16, 2017

page 2, left column, bottom

We provide a full-fledged implementation of HoneyBadgerBFT, which will we release as free open source software in the near future.

will we --> we will

@sbellem
Copy link
Contributor Author

sbellem commented Oct 22, 2017

DEFERRED PROOFS

[...]

Experiment 1. [...] The adversary selects N - 2f correct nodes and let S denote the union of their proposed transactions -- recall that the ACS protocol guarantees that the agreed set contains at least transactions proposed by N - 2f correct nodes.

contains at least transactions --> contains at least B/4 transactions (?)

Experiment 2. [...]
[...]
[...] If the average number of transactions across these epochs is smaller than 1/4 * B, D guesses that the ciphertexts are real; otherwise it guess they are random.

guess --> guesses (?)

@sbellem
Copy link
Contributor Author

sbellem commented Dec 12, 2017

Applicability to permissionless blockchains.
[...]
Several recent works have suggested the promising idea of leveraging either a slower, external blockchain such as Bitcoin or economic “proof-of-stake” assumptions involving the underlying currency itself [32, 32, 35, 37] to bootstrap faster BFT protocols, by selecting a random committee to perform BFT in every different epoch.

[32, 32, 35, 37] --> [32, 35, 37] ?

@sbellem
Copy link
Contributor Author

sbellem commented Aug 24, 2018

5.1 Bandwidth Breakdown and Evaluation

...
Bandwidth and breakdown findings. ...
...
The system’s effective throughput ... However, when when the batch size reaches 16384, ...

when when --> when

@sbellem
Copy link
Contributor Author

sbellem commented Aug 24, 2018

This issue was moved to initc3/HoneyBadgerBFT-Python#36

@sbellem sbellem closed this as completed Aug 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant