-
Notifications
You must be signed in to change notification settings - Fork 0
/
discussion.tex
81 lines (74 loc) · 4.45 KB
/
discussion.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
\section{Discussion \& Future Work}
\noindent
\myparagraph[Composability]
Because PoEM changes only the proof-of-work inequality, it can be composed with other
previously proposed improvements upon PoW to give cumulative benefits.
Such examples are different block topologies like
Bitcoin-NG~\cite{bitcoin-ng}, Fruit\-Chains~\cite{fruitchains},
Prism~\cite{prism}, Parallel Chains~\cite{parallel-chains},
PHANTOM~\cite{phantom}, SPECTRE~\cite{spectre}, GhostDAG~\cite{ghostdag},
GHOST~\cite{ghost},
Ledger Combiners~\cite{ledger-combiners} and HLCR~\cite{hlcr}.
A formal proof of the composability of PoEM with these protocols is left for future work.
\noindent
\myparagraph[Bias]
Whereas our security analysis was conducted for $\gamma = 0$,
the real-world PoEM deployment uses positive values for $\gamma$.
We also used (among others) positive values for $\gamma$ when conducting our experiments
in Section~\ref{sec:experiments}. We have experimentally observed that
increasing $\gamma$ improves the rate at which the
sum of independent random variables each distributed as $\Bern(\cdot) (\gamma + \Exp(\frac{1}{\ln2}))$
converges, but the expectations deteriorate as far as security is concerned.
We suspect that, for a given acceptable probability of failure given by the security
parameter $\kappa$, there is an optimal configuration $(g, \gamma)$ (and a corresponding $k$) that
minimizes the confirmation delay. This is supported by our experimental evidence in Section~\ref{sec:more-experiments}.
Can this optimal configuration be found analytically?
Additionally,
we know that, at the operating limit of $\gamma \to \infty$, the protocol
is exactly Bitcoin with an arbitrary tie-breaker, so we have proofs of security for both
$\gamma = 0$ and $\gamma \to \infty$, but not for $0 < \gamma < \infty$.
We leave the full formal analysis of these questions for future work,
although we note that the relevant Chernoff bounds for non-negative biases $\gamma$
are well-behaved, as we analytically prove in Lemma~\ref{lem:bern-exp}.
\noindent
\myparagraph[Work functions]
We used the function $\rwork(B) = \gamma - \lg \frac{\rH(B)}{T}$.
This definition corresponds to the intuitive idea that
each successful query to the random oracle reduces the number of possible evolutionary
paths of the system, thus reducing its ``entropy''
(hence the name \emph{\poem}, Proof of Entropy Minima).
An open question
is whether this function is optimal, or whether
a different function optimizes confirmation latency.
\noindent
\myparagraph[Tight bounds]
In our proofs, we have used the conservative configuration $f = \frac{\delta}{6}$,
which yields a small value for the honest block production rate $g$, following the model
of Backbone~\cite{backbone}. Follow up works in Bitcoin~\cite{eiar,tight-bounds} have shown tighter
operating limits for Bitcoin, and we expect that similar results can be obtained for PoEM.
We have experimentally demonstrated that consensus is achieved with higher values
of $g$ when the honest parties play against a private mining adversary. This instills
confidence, because we know from the work in~\cite{eiar} that this private mining attack
is indeed the best possible attack against Bitcoin in the continuous-time domain~\cite{bitcoin-made-simple}.
However, no such result exists for
PoEM. Showing that PoEM is secure for high values of $g$ against \emph{any} adversary,
or that indeed the private mining attack is also the best possible attack against PoEM,
is left for future work. Such an analysis poses technical challenges because, even though
PoEM might have better behavior of expected values, the concentration of the random
variables is worse than in Bitcoin.
\noindent
\myparagraph[Difficulty adjustment]
In our security proof, we assumed a static population in accordance with
the Bitcoin Backbone analysis~\cite{backbone}. The practical deployments of
both Bitcoin and PoEM adjust their difficulty in response to changes in the
miner population. Bitcoin was proven secure in this variable difficulty
setting~\cite{varbackbone}. One of the technical challenges in this analysis
is to also consider whether the value $\gamma$ should be adjusted in response
to changes in the miner population.
We leave the variable difficulty analysis of PoEM
for future work.
\noindent
\myparagraph[DAGs]
Some engineering work in our real-world deployment has indicated that using
PoEM's fork choice rule in a DAG-based blockchain with a particular topology
may be beneficial. More research is needed to explore this direction.