Merge pull request #15 from virgil/master
Did first pass of casper economics paper
This commit is contained in:
vbuterin
GitHub
commit
75b8a77bcf
|
|
@ -0,0 +1,43 @@
|
|||
\appendix
|
||||
\clearpage
|
||||
\part*{Appendix}
|
||||
|
||||
\section{Leak formula derivation}
|
||||
\label{app:leak}
|
||||
\todo{Put details of the derivation of the leak formula here.}
|
||||
|
||||
\section{Unused text}
|
||||
|
||||
\todo{This is where text goes that for which a home hasn't been found yet. If no home is found, it will be deleted.}
|
||||
|
||||
|
||||
|
||||
for the same \epoch and \hash as in \eqref{eq:msgPREPARE}. The $\hash$ is the block hash of the block at the start of the epoch. A hash $\hash$ being justified entails that all fresh (non-finalized) ancestor blocks are also justified. A hash $\hash$ being finalized entails that all ancestor blocks are also finalized, regardless of whether they were previously fresh or justified. An ``ideal execution'' of the protocol is one where, at the start of every epoch, every validator Prepares and Commits the first blockhash of each epoch, specifying the same $\epochsource$ and $\hashsource$.
|
||||
|
||||
In the Casper protocol, there exists a set of validators, and in each \textit{epoch} (see below) validators may send two kinds of messages: $$[PREPARE, epoch, hash, epoch_{source}, hash_{source}]$$ and $$[COMMIT, epoch, hash]$$
|
||||
|
||||
|
||||
If, during an epoch $e$, for some specific ancestry hash $h$, for any specific ($epoch_{source}, hash_{source}$ pair), there exist $\frac{2}{3}$ prepares of the form $$[PREPARE, e, h, epoch_{source}, hash_{source}]$$, then $h$ is considered \textit{justified}. If $\frac{2}{3}$ commits are sent of the form $$[COMMIT, e, h]$$ then $h$ is considered \textit{finalized}.
|
||||
|
||||
|
||||
\section{Notes to Authors}
|
||||
\subsection{Questions}
|
||||
\begin{itemize}
|
||||
\item True/False: The Dynasty counter increments iff there's been a finalization?
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Notes on Suggested Terminology}
|
||||
\begin{itemize}
|
||||
\item parent $\rightarrow$ predecessor.
|
||||
\item child $\rightarrow$ successor (unless want to emphasize there can be multiple candidate successors)
|
||||
\item ancestors $\rightarrow$ lineage
|
||||
\item to refer to the set of $\{$ predecessor, successor $\}$ $\rightarrow$ adjacent
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Todo}
|
||||
\begin{itemize}
|
||||
\item \sout{Reference the various Figures within the text so we more easily know what goes with what.}
|
||||
\item \todo{fill me in}
|
||||
\end{itemize}
|
||||
Binary file not shown.
|
|
@ -0,0 +1,334 @@
|
|||
%\title{Casper the Friendly Finality Gadget: Basic Structure}
|
||||
\title{A Parsimonious Stake-based Finalty Mechanism}
|
||||
\author{
|
||||
Vitalik Buterin \\
|
||||
Ethereum Foundation}
|
||||
|
||||
|
||||
\documentclass[12pt, final]{article}
|
||||
\input{eth_header.tex}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
%% Special symbols we'll probably iterate on
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% we will probably iterate on these symbols until we have a notation we like
|
||||
\newcommand{\epoch}{\ensuremath{e}\xspace}
|
||||
\newcommand{\hash}{\textnormal{h}\xspace}
|
||||
|
||||
% symbols for the epoch and hash source
|
||||
\newcommand{\epochsource}{\ensuremath{\epoch_{\star}}\xspace}
|
||||
\newcommand{\hashsource}{\ensuremath{\hash_{\star}}\xspace}
|
||||
|
||||
|
||||
\newcommand{\signature}{\ensuremath{\mathcal{S}}\xspace}
|
||||
|
||||
\newcommand{\totaldeposit}{\textnormal{TD}\xspace}
|
||||
|
||||
\newcommand{\gamesymbol}{\reflectbox{G}}
|
||||
|
||||
\newcommand{\msgPREPARE}{\textbf{\textsc{prepare}}\xspace}
|
||||
\newcommand{\msgCOMMIT}{\textbf{\textsc{commit}}\xspace}
|
||||
|
||||
|
||||
% Symbols for the Last Justified Epoch and Hash
|
||||
\newcommand{\epochLJ}{\ensuremath{\epoch_{\textnormal{LJ}}}\xspace}
|
||||
\newcommand{\hashLJ}{\ensuremath{\hash_{\textnormal{LJ}}}\xspace}
|
||||
|
||||
% Symbols for the Last Finalized Epoch and Hash
|
||||
\newcommand{\epochLF}{\ensuremath{\epoch_{\textnormal{LF}}}\xspace}
|
||||
\newcommand{\hashLF}{\ensuremath{\hash_{\textnormal{LF}}}\xspace}
|
||||
|
||||
% Griefing Factor symbol
|
||||
\newcommand{\GF}[1]{\mathds{GF}\left( #1 \right)\xspace}
|
||||
|
||||
% Genesis block symbol
|
||||
\newcommand{\Genesisblock}{\ensuremath{\mathds{G}}\xspace}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\maketitle
|
||||
\TODO{ \today }
|
||||
|
||||
\begin{abstract}
|
||||
We give an introduction to the consensus algorithm details of Casper: the Friendly Finality Gadget, as an overlay on an existing proof of work blockchain such as Ethereum. Byzantine fault tolerance analysis is included, but economic incentive analysis is out of scope. \todo{To be reworked at the very end}
|
||||
\end{abstract}
|
||||
|
||||
\section{Introduction}
|
||||
\label{sect:intro}
|
||||
\todo{Probably talk about prior Proof of Stake / Finality based work here.}
|
||||
|
||||
\section{Principles}
|
||||
\todo{This might be stuff that we can roll into the Introduction}
|
||||
Casper the Friendly Finality Gadget is an overlay on top of some kind of ``proposal mechanism'' - a mechanism which ``proposes'' blocks which the Casper mechanism can then set in stone by ``finalizing'' them. Casper depends on the proposal mechanism for liveness, but not safety; that is, if the proposal mechanism is entirely controlled by attackers, then the attackers can prevent Casper from finalizing any future checkpoints, but cannot cause a safety failure in Casper---i.e., they cannot force Casper to finalize two conflicting blocks.
|
||||
|
||||
The base mechanism is heavily inspired by partially synchronous systems such as Tendermint \cite{kwon2014tendermint} and PBFT \cite{castro1999practical} , and thus has $\frac{1}{3}$ Byzantine fault tolerance and is safe under asynchrony and dependent on the proposal mechanism for liveness.
|
||||
|
||||
In Section \ref{sect:leak} we introduce a modification which increases Byzantine fault tolerance to $\frac{1}{2}$, with the proviso that attackers with size $\frac{1}{3} < \alpha < \frac{1}{2}$ can delay new blocks being finalized by some period of time $D$ (think $D \approx$ 3 weeks), at the cost of a ``tradeoff synchrony assumption'' where fault tolerance decreases as network latency goes up, decreasing to potentially zero when network latency reaches $D$.
|
||||
|
||||
In the Casper Phase 1 implementation for Ethereum, the ``proposal mechanism'' is the existing proof of work chain, modified to have a greatly reduced block reward because the chain no longer relies as heavily on proof of work for security, and we describe how the Casper mechanism, and fork choice rule, can be ``overlaid'' onto the proof of work mechanism in order to add Casper's guarantees.
|
||||
|
||||
\section{The Protocol}
|
||||
\label{sect:protocol}
|
||||
|
||||
In the Casper protocol, there is a set of validators, and in each epoch validators have the ability to send two kinds of messages:
|
||||
|
||||
|
||||
\begin{table}[h!bt]
|
||||
\centering
|
||||
|
||||
\subfloat[\msgPREPARE format]{ \begin{tabular}{l l} \toprule
|
||||
\textbf{Notation} & \textbf{Description} \\
|
||||
\midrule
|
||||
\hash & the hash to justify \\
|
||||
\epoch & the current epoch \\
|
||||
$\hashsource$ & the most recent justified hash \\
|
||||
$\epochsource$ & the epoch containing hash $\hashsource$ \\
|
||||
\signature & signature from the validator's private key of the tuplet $(\hash,\epoch,\hashsource,\epochsource)$. \\
|
||||
\bottomrule
|
||||
\end{tabular} \label{tbl:prepare} }
|
||||
|
||||
\subfloat[\msgCOMMIT format]{ \begin{tabular}{l l} \toprule
|
||||
\textbf{Notation} & \textbf{Description} \\
|
||||
\midrule
|
||||
\hash & the hash to finalize \\
|
||||
\epoch & the current epoch \\
|
||||
\signature & signature from the validator's private key \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\label{tbl:commit} }
|
||||
\caption{The schematic of the \msgPREPARE and \msgCOMMIT messages.}
|
||||
\label{fig:messages}
|
||||
\end{table}
|
||||
|
||||
|
||||
Each validator has a \emph{deposit size}; when a validator joins their deposit size is equal to the number of coins that they deposited, and from there on each validator's deposit size rises and falls with rewards and penalties. For the rest of this paper, when we say ``$\frac{2}{3}$ of validators'', we are referring to a \emph{deposit-weighted} fraction; that is, a set of validators whose sum deposit size equals to at least $\frac{2}{3}$ of the total deposit size of the entire set of validators.
|
||||
|
||||
Every hash $\hash$ has one of three possible states: \emph{fresh}, \emph{justified}, and \emph{finalized}. Every hash starts as \emph{fresh}. The hash at the beginning of the current epoch converts from fresh to \emph{justified} if, during the current epoch $\epoch$, $\frac{2}{3}$ Prepares are sent of the form
|
||||
|
||||
\begin{equation}
|
||||
\langle \msgPREPARE, \epoch, \hash, \epochsource, \hashsource, \signature \rangle
|
||||
\label{eq:msgPREPARE}
|
||||
\end{equation}
|
||||
|
||||
for some specific $\epochsource$ and $\hashsource$. A hash $\hash$ can only be justified if and only if its $\hashsource$ is already justified or finalized.
|
||||
|
||||
Additionally, a hash converts from justified to \emph{finalized}, if $\frac{2}{3}$ of validators Commit
|
||||
|
||||
\begin{equation}
|
||||
\langle \msgCOMMIT, \epoch, \hash, \signature \rangle \; ,
|
||||
\label{eq:msgCOMMIT}
|
||||
\end{equation}
|
||||
|
||||
for the same \epoch and \hash as in \eqref{eq:msgPREPARE}. The $\hash$ is the block hash of the block at the start of the epoch. A hash $\hash$ being justified entails that all fresh (non-finalized) preceding blocks are also justified. A hash $\hash$ being finalized entails that all preceding blocks are also finalized, regardless of whether they were previously fresh or justified. An ``ideal execution'' of the protocol is one where, at the start of every epoch, every validator Prepares and Commits the first blockhash of each epoch, specifying the same $\epochsource$ and $\hashsource$.
|
||||
|
||||
|
||||
\begin{figure}[h!tb]
|
||||
\centering
|
||||
\includegraphics[width=5.5in]{prepares_commits.png}
|
||||
\caption{Illustrating the sequence of Prepares and Commits. \todo{revise?}}
|
||||
\label{fig:prepares_and_commits}
|
||||
\end{figure}
|
||||
|
||||
An \textit{epoch} is a period of 100 blocks; epoch $n$ begins at block $n * 100$ and ends at block $n * 100 + 99$.
|
||||
The final in each epoch in a \emph{checkpoint block}. Checkpoint blocks are special
|
||||
|
||||
A \textit{checkpoint for epoch $n$} is a block with number $n * 100 - 1$; in a smoothly running blockchain there will usually be only one checkpoint per epoch, but due to natural network latency or deliberate attacks there may be multiple competing checkpoints during some epochs. The \textit{predecessor} of a checkpoint is the checkpoint in the prior epoch, and an \textit{lineage} of a checkpoint is the set of all preceding checkpoints, recursively, to the Genesis block \Genesisblock.
|
||||
|
||||
\TODO{Probably define some mathematical notation here for Block $B$, Checkpoint $C$, Predecessor, Successor, Lineage, etc.}
|
||||
|
||||
We define the \textit{lineage hash} of a checkpoint as follows:
|
||||
|
||||
\begin{itemize}
|
||||
\item The lineage hash of the implied ``genesis checkpoint'' of epoch 0 is thirty two zero bytes.
|
||||
\item The lineage hash of any other checkpoint is the keccak256 hash \todo{cite} of the lineage hash of its predecessor checkpoint concatenated with the hash of the checkpoint.
|
||||
|
||||
\begin{equation}
|
||||
AH(n) \equiv \texttt{keccak256}\left[ \texttt{CONCAT}\left( AH(n-1), \texttt{keccak256}[C_n] \right)\right]
|
||||
\end{equation}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
Lineage hashes thus form a direct hash chain, and otherwise have a one-to-one correspondence with checkpoint hashes.
|
||||
|
||||
During epoch $n$, validators are expected to send prepare and commit messages specifying $n$ as their \epoch, and the lineage hash of some checkpoint for epoch $n$ as their \hash. Prepare messages may specify as \hashsource a checkpoint for any previous epoch (preferably the preceding checkpoint) of \hash, and which is \textit{justified} (see below), and the \epochsource is expected to be the epoch of that checkpoint.
|
||||
|
||||
Each validator has a \textit{deposit size}; when a validator joins their deposit size is equal to the number of coins that they deposited, and from there on each validator's deposit size rises and falls as the validator receives rewards and penalties. For the rest of this paper, when we say ``$\frac{2}{3}$ of validators'', we are referring to a \textit{deposit-weighted} fraction; that is, a set of validators whose combined deposit size equals to at least $\frac{2}{3}$ of the total deposit size of the entire set of validators. We initially consider the set of validators, and their deposit sizes to be static static, but in Section \ref{sect:join_and_leave} show how to validators can join and leave the validator set.
|
||||
|
||||
|
||||
We also add the following new requirements:
|
||||
|
||||
\begin{itemize}
|
||||
\item For a checkpoint to be finalized, it must be justified.
|
||||
\item For a checkpoint to be justified, the \hashsource used to justify it must itself be justified.
|
||||
\item Prepare and commit messages are only accepted as part of blocks; that is, for a client to consider a checkpoint as finalized, the client must see a chain \todo{notation?} such that the chain terminating at that block, $\frac{2}{3}$ commits for that hash have been included and processed.
|
||||
\end{itemize}
|
||||
|
||||
This immensely simplifies our finalty mechanism because we can now have a fork choice rule where the ``score'' of a block only depends on the block and its children, putting it into a similar category as more traditional PoW-based fork choice rules such as the longest chain rule and GHOST\cite{sompolinsky2013accelerating}. However, this fork choice rule is also \textit{finality-bearing}: there exists a ``finality'' mechanism that has the property that (i) the fork choice rule always prefers finalized blocks over non-finalized competing blocks, and (ii) it is impossible for two incompatible checkpoints to be finalized unless at least $\frac{1}{3}$ of the validators violated a Casper Commandment (a.k.a. slashing conditions),
|
||||
|
||||
\begin{enumerate}
|
||||
\item[\textbf{I.}] \textsc{A validator shalt not publish two or more nonidentical Prepares for same epoch.}
|
||||
|
||||
This is equivalent to that each validator may Prepare to exactly one (\hash, \epochsource, \hashsource) triplet per epoch.
|
||||
|
||||
\item[\textbf{II.}] \textsc{A validator shalt not publish an Commit between the epochs of a Prepare statement.}
|
||||
|
||||
Equivalently, a validator will not publish
|
||||
|
||||
\begin{equation*}
|
||||
\langle \msgPREPARE, \epoch_p, \hash_p, \epochsource, \hashsource, \signature \rangle \hspace{0.5in} \textnormal{\textsc{and}} \hspace{0.5in} \langle \msgCOMMIT, \epoch_c, \hash_c, \signature \rangle \;,
|
||||
\label{eq:msgPREPARE}
|
||||
\end{equation*}
|
||||
|
||||
where the epochs satisfy $\epochsource < \epoch_c < \epoch_p$.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
\begin{lemma}[Enforcable Slashing Conditions]
|
||||
\label{lemma:slashingconditions}
|
||||
If a group of attackers violates a slashing condition, their deposits will be slashed as long as \todo{condition here.}
|
||||
\begin{proof}
|
||||
\todo{Proof goes here.}
|
||||
\end{proof}
|
||||
\end{lemma}
|
||||
|
||||
|
||||
Earlier versions of Casper had four slashing conditions,\cite{minslashing} but we can reduce to two because of the three new requirements above; they ensure that blocks will not register commits or prepares that violate the other two conditions.
|
||||
|
||||
\section{Proofs of Safety and Plausible Liveness}
|
||||
\label{sect:theorems}
|
||||
|
||||
We give a proof of two properties of Casper: \textit{accountable safety} and \textit{plausible liveness}. Accountable safety means that two conflicting checkpoints cannot be finalized unless $\geq \frac{1}{3}$ of validators violate a slashing condition (meaning at least $\frac{\totaldeposit}{3}$ is lost). Honest validators will never violate slashing conditions, so this implies the usual Byzantine fault tolerance safety property, but expressing this in terms of slashing conditions means that we are actually proving a stronger claim: if two conflicting checkpoints get finalized, then at least $\frac{1}{3}$ of validators were malicious, \textit{and we know whom to blame, and so we can maximally penalize them in order to make such faults expensive}.
|
||||
|
||||
Plausible liveness means that it is always possible for $\frac{2}{3}$ of honest validators to finalize a new checkpoint, regardless of what previous events took place.
|
||||
|
||||
In \figref{fig:conflicting_checkpoints}, we see two conflicting checkpoints $A$ (epoch $e_A$) and $B$ (epoch $e_B$) are finalized.
|
||||
|
||||
\begin{figure}[h!tb]
|
||||
\centering
|
||||
\includegraphics[width=5in]{conflicting_checkpoints.png}
|
||||
\caption{\todo{fill me in.}}
|
||||
\label{fig:conflicting_checkpoints}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\begin{theorem}[Accountable Safety]
|
||||
\label{theorem:safety}
|
||||
Two conflicting checkpoints cannot be finalized unless $\geq \frac{1}{3}$ of validators violate a slashing condition (meaning at least $\frac{\totaldeposit}{3}$ is lost).
|
||||
|
||||
\begin{proof}
|
||||
This implies $\frac{2}{3}$ commits and $\frac{2}{3}$ prepares in epochs $\epoch_A$ and $e_B$. In the trivial case where $\epoch_A = \epoch_B$, this implies that some intersection of $\frac{1}{3}$ of validators must have violated \textbf{NO\_DBL\_PREPARE}. In other cases, there must exist two chains $\Genesisblock < \ldots < \epoch_A^2 < \epoch_A^1 < \epoch_A$ and $\Genesisblock < \ldots < \epoch_B^2 < \epoch_B^1 < \epoch_B$ of justified checkpoints, both terminating at the genesis. Suppose without loss of generality that $\epoch_A > \epoch_B$. Then, there must be some $\epoch_A^i$ that either $\epoch_A^i = ]\epoch_B$ or $\epoch_A^i > \epoch_B > \epoch_A^{i+1}$. In the first case, since $A^i$ and $B$ both have $\frac{2}{3}$ prepares, at least $\frac{1}{3}$ of validators violated \textbf{NO\_DBL\_PREPARE}. Otherwise, $B$ has $\frac{2}{3}$ commits and there exist $\frac{2}{3}$ prepares with $\epoch > B$ and $\epochsource < B$, so at least $\frac{1}{3}$ of validators violated \textbf{PREPARE\_COMMIT\_CONSISTENCY}. This proves accountable safety.
|
||||
\end{proof}
|
||||
\end{theorem}
|
||||
|
||||
|
||||
|
||||
|
||||
\begin{theorem}[Plausible Liveness]
|
||||
\label{theorem:liveness}
|
||||
It is always possible for $\frac{2}{3}$ of honest validators to finalize a new checkpoint, regardless of what previous events took place.
|
||||
|
||||
\begin{proof}
|
||||
Suppose that all existing validators have sent some sequence of prepare and commit messages. Let $M$ with epoch $\epoch_M$ be the highest-epoch checkpoint that was justified. Honest validators have not committed on any block which is not justified. Hence, neither slashing condition stops them from making prepares on a child of $M$, using $\epoch_M$ as $\epochsource$, and then committing this child.
|
||||
\end{proof}
|
||||
|
||||
\end{theorem}
|
||||
|
||||
\section{Fork Choice Rule}
|
||||
\label{sect:forkchoice}
|
||||
|
||||
The mechanism described above ensures \textit{plausible liveness}; however, it by itself does not ensure \textit{actual liveness} - that is, while the mechanism cannot get stuck in the strict sense, it could still enter a scenario where the proposal mechanism (i.e. the proof of work chain) gets into a state where it never ends up creating a checkpoint that could get finalized.
|
||||
|
||||
In \figref{fig:forkchoice} we see one possible example. In this case, $HASH1$ or any descendant thereof cannot be finalized without slashing $\frac{1}{6}$ of validators. However, miners on a proof of work chain would interpret $HASH1$ as the head and forever keep mining descendants of it, ignoring the chain based on $HASH0^\prime$ which actually could get finalized.
|
||||
|
||||
\begin{figure}[h!tb]
|
||||
\centering
|
||||
\includegraphics[width=5.5in]{fork4.png}
|
||||
\caption{\todo{fill me in.}}
|
||||
\label{fig:forkchoice}
|
||||
\end{figure}
|
||||
|
||||
In fact, when \textit{any} checkpoint gets $k > \frac{1}{3}$ commits, no conflicting checkpoint can get finalized without $k - \frac{1}{3}$ of validators getting slashed. This necessitates modifying the fork choice rule used by participants in the underlying proposal mechanism (as well as users and validators): instead of blindly following a longest-chain rule, there needs to be an overriding rule that (i) finalized checkpoints are favored, and (ii) when there are no further finalized checkpoints, checkpoints with more (justified) commits are favored.
|
||||
|
||||
One complete description of such a rule would be:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Start with HEAD equal to the genesis of the chain.
|
||||
\item Select the descendant checkpoint of HEAD with the most commits (only justified checkpoints are admissible)
|
||||
\item Repeat (2) until no descendant with commits exists.
|
||||
\item Choose the longest proof of work chain from there.
|
||||
\end{enumerate}
|
||||
|
||||
The commit-following part of this rule can be viewed in some ways as mirroring the ``greegy heaviest observed subtree'' (GHOST) rule that has been proposed for proof of work chains\cite{sompolinsky2013accelerating}. The symmetry is as follows, in GHOST, a node starts with the head at the genesis, then begins to move forward down the chain, and if it encounters a block with multiple children then it chooses the child that has the larger quantity of work built on top of it (including the child block itself and its descendants).
|
||||
|
||||
In this algorithm, we follow a similar approach, except we repeatedly seek the child that comes the closest to achieving finality. Commits on a descendant are implicitly commits on all of its lineage, and so if a given descendant of a given block has more commits than any other descendant, then we know that all children along the chain from the head to this descendant are closer to finality than any of their siblings; hence, looking for the \textit{descendant} with the most commits and not just the \textit{child} replicates the GHOST principle most faithfully. Finalizing a checkpoint requires $\frac{2}{3}$ commits within a \textit{single} epoch, and so we do not try to sum up commits across epochs and instead simply take the maximum.
|
||||
|
||||
This rule ensures that if there is a checkpoint such that no conflicting checkpoint can be finalized without at least some validators violating slashing conditions, then this is the checkpoint that will be viewed as the ``head'' and thus that validators will try to commit on.
|
||||
|
||||
\section{Allowing Dynamic Validator Sets}
|
||||
\label{sect:join_and_leave}
|
||||
|
||||
The set of validators needs to be able to change. New validators need to be able to join, and existing validators need to be able to leave. To accomplish this, we define a variable kept track of in the state called the \textit{dynasty} counter. When a user sends a ``deposit'' transaction to become a validator, if this transaction is included in dynasty $n$, then the validator will be \textit{inducted} in dynasty $n+2$. The dynasty counter increments when the chain detects that the checkpoint of the current epoch that is part of its own history has been finalized (that is, the checkpoint of epoch \epoch must be finalized during epoch \epoch, and the chain must learn about this before epoch \epoch ends). In simpler terms, when a user sends a ``deposit'' transaction, they need to wait for the transaction to be finalized, and then they need to wait again for that epoch to be finalized; after this, they become part of the validator set. We call such a validator's \textit{start dynasty} $n+2$. \todo{The conditions here feel different. Do we mean we want to have two \emph{perfect finalizations} (finalizing the epoch immediately prior) or simply two finalizations?}
|
||||
|
||||
For a validator to leave, ze must send a ``withdraw'' message. If their withdraw message gets included during dynasty $n$, the validator similarly leaves the validator set during dynasty $n+2$; we call $n+2$ their \textit{end dynasty}. When a validator withdraws, their deposit is locked for four months \todo{how determined?} before they can take their money out; if they are caught violating a slashing condition within that time then their deposit is forfeited.
|
||||
|
||||
For a checkpoint to be justified, it must be prepared by a set of validators which contains (i) at least $\frac{2}{3}$ of the current dynasty (that is, validators with $startDynasty \le curDynasty < endDynasty$), and (ii) at least $\frac{2}{3}$ of the previous dyansty (that is, validators with $startDynasty \le curDynasty - 1 < endDynasty$. Finalization with commits works similarly. The current and previous dynasties will usually greatly overlap; but in cases where they substantially diverge this ``stitching'' mechanism ensures that dynasty divergences do not lead to situations where a finality reversion or other failure can happen because different messages are signed by different validator sets and so equivocation is avoided.
|
||||
|
||||
\begin{figure}[h!tb]
|
||||
\centering
|
||||
\includegraphics[width=4.5in]{validator_set_misalignment.png}
|
||||
\caption{\todo{This is meant to demonstrate the need for the ``stitching'' of dynamic validator sets, correct?}}
|
||||
\label{fig:dynamic}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Recovering from Castastrophic Crashes}
|
||||
\label{sect:leak}
|
||||
|
||||
Suppose that $>\frac{1}{3}$ of validators crash-fail at the same time---i.e, they are no longer connected to the network due to a network partition, computer failure, or are malicious actors. Then, no later checkpoint will be able to get finalized.
|
||||
|
||||
We can recover from this by instituting a ```leak'' (eq.~\ref{eq:leakformula}) which increases the longer validators do not prepare or commit any checkpoints, until eventually their deposit sizes decrease low enough that the validators that \textit{are} preparing and committing are a $\frac{2}{3}$ supermajority.
|
||||
|
||||
|
||||
Given two constants $B$, the number of blocks until leak completely dissipates an inactive vaidator's deposit, and $s$ the ``steepness'' of the curve, we have the formula for the validator leak as a function of the number of inactive blocks as,
|
||||
|
||||
\begin{equation}
|
||||
\operatorname{leak}(x) = \frac{s + 1}{B^{s + 1}} x^s \; , \textnormal{\todo{notation likely to be changed.}}
|
||||
\label{eq:leakformula}
|
||||
\end{equation}
|
||||
for which the derivation is given in Appendix \ref{app:leak}. One can set parameters $B$ and $s$ depending on the desired penalty curves.
|
||||
|
||||
Note that this does introduce the possibility of two conflicting checkpoints being finalized, with validators only losing money on one of the two checkpoints as seen in \figref{fig:commitsync}.
|
||||
|
||||
\begin{figure}[h!tb]
|
||||
\centering
|
||||
\includegraphics[width=4in]{CommitsSync.png}
|
||||
\caption{\todo{caption here.}}
|
||||
\label{fig:commitsync}
|
||||
\end{figure}
|
||||
|
||||
If the goal is simply to achieve maximally close to 50\% fault tolerance, then clients should simply favor the finalized checkpoint that they received earlier. However, if clients are also interested in defeating 51\% censorship attacks, then they may want to at least sometimes choose the minority chain. All forms of ``51\% attacks'' can thus be resolved fairly cleanly via ``user-activated soft forks'' that reject what would normally be the dominant chain. Particularly, note that finalizing even one block on the dominant chain precludes the attacking validators from preparing on the minority chain because of Commandment II, at least until their balances decrease to the point where the minority can commit, so such a fork would also serve the function of costing the majority attacker a very large portion of their deposits.
|
||||
|
||||
\section{Conclusions}
|
||||
|
||||
This introduces the basic workings of Casper the Friendly Finality Gadget's prepare and commit mechanism and fork choice rule, in the context of Byzantine fault tolerance analysis. Separate papers will serve the role of explaining and analyzing incentives inside of Casper, and the different ways that they can be parametrized and the consequences of these paramtrizations.
|
||||
|
||||
|
||||
\textbf{Future Work.} \todo{fill me in}
|
||||
|
||||
\textbf{Acknowledgements.} We thank Virgil Griffith for review and Sandro Lera for mathematics.
|
||||
|
||||
|
||||
%\section{References}
|
||||
\bibliographystyle{abbrv}
|
||||
\bibliography{ethereum}
|
||||
|
||||
\input{appendix.tex}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
|
||||
\end{document}
|
||||
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
% make in NIPS format
|
||||
\usepackage{nips10submit_e}
|
||||
\nipsfinalcopy
|
||||
|
||||
|
||||
|
||||
\usepackage{graphicx}
|
||||
\DeclareGraphicsExtensions{.pdf,.eps,.png,.jpg} % search for .pdf, then .eps, then .pngs, then .jpg
|
||||
|
||||
% look in these subdirectories for graphics referenced by \includegraphics
|
||||
% each entry must end with a /
|
||||
\graphicspath{{figs/}{figures/}{images/}{./}}
|
||||
|
||||
\newcommand*{\red}[1]{ \color{red} #1}
|
||||
|
||||
\usepackage{tabularx}
|
||||
\usepackage{url}
|
||||
\usepackage{cite}
|
||||
\usepackage{amsmath}
|
||||
|
||||
%\usepackage{ lmodern } % I prefer this over times
|
||||
|
||||
\usepackage{array} % replacement for eqnarray. Must be BEFORE \usepackage{arydshln}
|
||||
\usepackage{units} % for \nicefrac{\alpha}{\beta}
|
||||
|
||||
|
||||
\usepackage{amsthm} % for theorems
|
||||
\newtheorem{definition}{Definition}
|
||||
|
||||
%\usepackage{microtype}
|
||||
|
||||
%\usepackage{wasysym}
|
||||
|
||||
\usepackage{textcomp, marvosym} % pretty symbols
|
||||
\usepackage{booktabs} % for much better looking tables
|
||||
|
||||
% for indicator functions
|
||||
\usepackage{dsfont}
|
||||
|
||||
% For automatic capitalizaton of section names, etc.
|
||||
\usepackage{titlesec,titlecaps}
|
||||
|
||||
|
||||
\Addlcwords{is with of the and in}
|
||||
%\Addlcwords{of the}
|
||||
%\Addlcwords{and}
|
||||
\titleformat{\section}[block]{}{\normalfont\Large\bfseries\thesection.\;}{0pt}{\formatsectiontitle}
|
||||
\newcommand{\formatsectiontitle}[1]{\normalfont\Large\bfseries\titlecap{#1}}
|
||||
|
||||
\titleformat{\subsection}[block]{}{\normalfont\large\bfseries\thesubsection.\;}{0pt}{\formatsubsectiontitle}
|
||||
\newcommand{\formatsubsectiontitle}[1]{\normalfont\large\bfseries\titlecap{#1}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
% for pretty Euler script
|
||||
\usepackage[mathscr]{euscript}
|
||||
\usepackage{bold-extra}
|
||||
|
||||
|
||||
|
||||
\usepackage{fullpage} % save trees
|
||||
|
||||
\usepackage{subfig}
|
||||
%\usepackage{float} % for \subfloat
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%% More customizable Lists
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% Better symbols custom enumerative lists, define any symbol you'd like
|
||||
\usepackage{enumitem}
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%% Custom Symbols
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% \xspace at the end of custom macros never fucks up spacing.
|
||||
% example of best practice: \newcommand{\apples}{\textsf{AppLeS}\xspace}
|
||||
\usepackage{xspace}
|
||||
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%% Abbreviations you'll always want
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
\newcommand*{\TODO}[1]{{\centering {\sffamily \color{red} #1} \vskip10pt }}
|
||||
\newcommand*{\todo}[1]{{\sffamily [{\color{red} #1}]}}
|
||||
\newcommand*{\fix}[1]{{\sffamily [{\textnormal{\color{red} #1}}]}}
|
||||
|
||||
|
||||
|
||||
%-----------------------------------------------------------------------------
|
||||
% Cross references
|
||||
%-----------------------------------------------------------------------------
|
||||
% The following code defines how you make references to figures, tables, etc...
|
||||
% It is defined in one place only, and can be modified for all references
|
||||
% in the document at the same time.
|
||||
% Instead of typing each time: "see Fig. \ref{myfig}" you can create a command
|
||||
% \figref which will do the job. Then in text you only type \figref{myfig} and LaTeX
|
||||
% will do the rest.
|
||||
\newcommand{\tblref}[1]{Table~\ref{#1}}
|
||||
%\renewcommand*{\figref}[1]{Fig.~\ref{#1}}
|
||||
\renewcommand{\eqref}[1]{eq.~\ref{#1}}
|
||||
|
||||
|
||||
\newcommand{\figref}[1]{Figure~\ref{#1}}
|
||||
\newcommand{\Figref}[1]{Figure~\ref{#1}}
|
||||
\newtheorem{theorem}{Theorem}
|
||||
\newtheorem{lemma}[theorem]{Lemma}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
% for \sout{} for strikeout
|
||||
\usepackage[normalem]{ulem}
|
||||
|
||||
|
||||
% for better manipulation of tables
|
||||
\usepackage{makecell}
|
||||
\renewcommand\theadfont{\bfseries}
|
||||
|
||||
|
||||
%-----------------------------------------------------------------------------
|
||||
% Misc symbols that I like
|
||||
%-----------------------------------------------------------------------------
|
||||
\newcommand*{\opname}[1]{\operatorname{#1}}
|
||||
|
||||
|
||||
\renewcommand*{\to}{\rightarrow}
|
||||
|
||||
|
||||
%%%%
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,643 @@
|
|||
%% This BibTeX bibliography file was created using BibDesk.
|
||||
%% http://bibdesk.sourceforge.net/
|
||||
|
||||
%% Created for Virgil Griffith at 2017-04-21 14:15:31 +0800
|
||||
|
||||
|
||||
%% Saved with string encoding Unicode (UTF-8)
|
||||
|
||||
@inproceedings{castro1999practical,
|
||||
title={Practical Byzantine fault tolerance},
|
||||
author={Castro, Miguel and Liskov, Barbara and others},
|
||||
booktitle={OSDI},
|
||||
volume={99},
|
||||
pages={173--186},
|
||||
year={1999}
|
||||
}
|
||||
|
||||
@article{sompolinsky2013accelerating,
|
||||
title={Accelerating Bitcoin's Transaction Processing. Fast Money Grows on Trees, Not Chains.},
|
||||
author={Sompolinsky, Yonatan and Zohar, Aviv},
|
||||
journal={IACR Cryptology ePrint Archive},
|
||||
volume={2013},
|
||||
number={881},
|
||||
year={2013}
|
||||
}
|
||||
|
||||
@misc{kwon2014tendermint,
|
||||
title={Tendermint: Consensus without mining},
|
||||
year={2014}
|
||||
author={Kwon, Jae},
|
||||
url={https://tendermint.com/static/docs/tendermint.pdf},
|
||||
year={2014}
|
||||
}
|
||||
|
||||
@article{monderer1996potential,
|
||||
title={Potential games},
|
||||
author={Monderer, Dov and Shapley, Lloyd S},
|
||||
journal={Games and economic behavior},
|
||||
volume={14},
|
||||
number={1},
|
||||
pages={124--143},
|
||||
year={1996},
|
||||
publisher={Elsevier}
|
||||
}
|
||||
|
||||
@misc{vasin2014blackcoin,
|
||||
title={Blackcoin’s proof-of-stake protocol v2},
|
||||
author={Vasin, Pavel},
|
||||
year={2014},
|
||||
publisher={Tech. rep. URL: http://blackcoin. co/blackcoin-pos-protocol-v2-whitepaper. pdf}
|
||||
}
|
||||
|
||||
@article{king2012ppcoin,
|
||||
title={Ppcoin: Peer-to-peer crypto-currency with proof-of-stake},
|
||||
author={King, Sunny and Nadal, Scott},
|
||||
journal={self-published paper, August},
|
||||
volume={19},
|
||||
year={2012}
|
||||
}
|
||||
|
||||
@inproceedings{bentov2016pos,
|
||||
title={Cryptocurrencies without proof of work},
|
||||
author={Bentov, Iddo and Gabizon, Ariel and Mizrahi, Alex},
|
||||
booktitle={International Conference on Financial Cryptography and Data Security},
|
||||
pages={142--157},
|
||||
year={2016},
|
||||
organization={Springer}
|
||||
}
|
||||
|
||||
|
||||
@inproceedings{selfishminingBTC,
|
||||
title={Optimal selfish mining strategies in bitcoin},
|
||||
author={Sapirshtein, Ayelet and Sompolinsky, Yonatan and Zohar, Aviv},
|
||||
booktitle={International Conference on Financial Cryptography and Data Security},
|
||||
pages={515--532},
|
||||
year={2016},
|
||||
organization={Springer}
|
||||
}
|
||||
|
||||
@misc{minslashing,
|
||||
title={Minimal Slashing Conditions},
|
||||
author={Vitalik Buterin},
|
||||
year={2017},
|
||||
month={03},
|
||||
day={02},
|
||||
url={https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c}
|
||||
}
|
||||
|
||||
|
||||
@misc{truebit,
|
||||
title={A scalable verification solution for blockchains},
|
||||
author={Jason Teustch and Christian Reitwießner},
|
||||
year={2017},
|
||||
month={03},
|
||||
day={07},
|
||||
url={https://truebit.io/}
|
||||
}
|
||||
|
||||
|
||||
@article{ostrom2002,
|
||||
title={Type of good and collective action},
|
||||
author={Ostrom, Elinor},
|
||||
journal={unpublished paper},
|
||||
pages={15},
|
||||
year={2002}
|
||||
}
|
||||
|
||||
@misc{barder14,
|
||||
title={A Global Carbon Tax or Cap-and-Trade? Part 1: The Economic Arguments},
|
||||
author={Alice Lépissier and Owen Barder},
|
||||
year={2014},
|
||||
month={09},
|
||||
day={08},
|
||||
url={https://www.cgdev.org/blog/global-carbon-tax-or-cap-and-trade-part-1-economic-arguments}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@misc{braveICO,
|
||||
author={Jon Southurst},
|
||||
title={BAT Token Sale Causes Hours of Ethereum Network Delays},
|
||||
year={2017},
|
||||
month={05},
|
||||
day={31},
|
||||
url={http://www.bitsonline.com/bat-sale-ethereum-network-delays/}
|
||||
}
|
||||
|
||||
|
||||
|
||||
@techreport{ibm2011,
|
||||
title = {GPFS Scans 10 Billion Files in 43 Minutes},
|
||||
author = {Richard F. Freitas, Joe Slember, Wayne Sawdon, and Lawrence Chiu},
|
||||
year = {2011},
|
||||
institution = {IBM},
|
||||
month = {07},
|
||||
day={22},
|
||||
url={https://domino.research.ibm.com/library/CyberDig.nsf/papers/4A50C2D66A1F90F7852578E3005A2034/$File/rj10484.pdf}
|
||||
}
|
||||
|
||||
|
||||
|
||||
@misc{infura,
|
||||
author={Consensys},
|
||||
title={INFURA},
|
||||
year={2017},
|
||||
month={06},
|
||||
day={01},
|
||||
url={https://infura.io}
|
||||
}
|
||||
|
||||
|
||||
@misc{spectrumetcalfe,
|
||||
author={Bob Briscoe, Andrew Odlyzko, and Benjamin Tilly},
|
||||
title={Metcalfe's Law is Wrong},
|
||||
year={2006},
|
||||
month={06},
|
||||
day={01},
|
||||
url={http://spectrum.ieee.org/computing/networks/metcalfes-law-is-wrong}
|
||||
}
|
||||
|
||||
@misc{env-econ,
|
||||
author={Tim Haab},
|
||||
title={The long run elasticity of demand for gas},
|
||||
year={2008},
|
||||
month={06},
|
||||
day={23},
|
||||
url={http://www.env-econ.net/2008/06/the-long-run-el.html}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@inproceedings{cornell-position,
|
||||
title={On Scaling Decentralized Blockchains},
|
||||
author={Kyle Croman, Christian Decker, Ittay Eyal, Adem Efe Gencer, Ari Juels},
|
||||
Year={2017},
|
||||
Booktitle={3rd Workshop on Bitcoin and Blockchain Research},
|
||||
Organization={International Financial Cryptography Association}
|
||||
url={http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@misc{medium-codetract,
|
||||
author={CodeTract},
|
||||
title={BAT ICO, USD 35 million in 24 seconds, gas and gasPrice},
|
||||
year={2017},
|
||||
month={06},
|
||||
day={01},
|
||||
url={https://medium.com/@codetractio/bat-ico-usd-35-million-in-24-seconds-gas-and-gasprice-6cdde370a615}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@misc{vitalik-uncle-rate,
|
||||
author={Vitalik Buterin},
|
||||
title={Uncle Rate and Transaction Fee Analysis},
|
||||
year={2016},
|
||||
month={10},
|
||||
day={31},
|
||||
url={https://blog.ethereum.org/2016/10/31/uncle-rate-transaction-fee-analysis/}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@misc{vitalik-twitter1,
|
||||
author={Vitalik Buterin},
|
||||
title={Tweet},
|
||||
year={2017},
|
||||
month={06},
|
||||
day={03},
|
||||
url={https://twitter.com/VitalikButerin/status/871218258212290560}
|
||||
}
|
||||
|
||||
|
||||
|
||||
@misc{reddit-rec-miners,
|
||||
author={Hudson Jameson},
|
||||
title={Recommendations to miners to change gas limit and gas price settings},
|
||||
year={2017},
|
||||
month={05},
|
||||
day={31},
|
||||
url={https://www.reddit.com/r/ethereum/comments/6ehp60/recommendations_to_miners_to_change_gas_limit_and/}
|
||||
}
|
||||
|
||||
|
||||
|
||||
@misc{coindesk-btc-txn-fee,
|
||||
author={Danny Bradbury},
|
||||
title={Bitcoin Transaction Fees To Be Slashed Tenfold},
|
||||
year={2014},
|
||||
month={02},
|
||||
day={28},
|
||||
url={http://www.coindesk.com/bitcoin-transaction-fees-slashed-tenfold/}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@misc{vitalik-coord,
|
||||
author={Vitalik Buterin},
|
||||
title={Engineering Security Through Coordination Problems},
|
||||
year={2017},
|
||||
month={05},
|
||||
day={08},
|
||||
url={http://vitalik.ca/general/2017/05/08/coordination_problems.html}
|
||||
}
|
||||
|
||||
@misc{etherchaingas,
|
||||
author={Etherchain},
|
||||
title={Economic gas price estimation},
|
||||
year={2017},
|
||||
month={05},
|
||||
day={1},
|
||||
url={https://etherchain.org/statistics/gasPrice}
|
||||
}
|
||||
|
||||
@misc{40years,
|
||||
author = {Karl Rupp},
|
||||
title = {40 Years of Microprocessor Trend Data},
|
||||
year = {2015},
|
||||
month={06},
|
||||
day={25},
|
||||
url = {https://www.karlrupp.net/2015/06/40-years-of-microprocessor-trend-data/},
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@misc{wiki:runaway,
|
||||
author = {Wikipedia},
|
||||
title = {Runaway climate change --- Wikipedia{,} The Free Encyclopedia},
|
||||
year = {2017},
|
||||
url = {https://en.wikipedia.org/w/index.php?title=Runaway_climate_change&oldid=776345569},
|
||||
note = {[Online; accessed 5-May-2017]}
|
||||
}
|
||||
|
||||
@misc{wood2014ethereum,
|
||||
title={Ethereum: A Secure Decentralized Generalized Transaction Ledger},
|
||||
author={Gavin Wood},
|
||||
year={2014},
|
||||
url={http://yellowpaper.io/}
|
||||
}
|
||||
|
||||
@article{weitzman1974prices,
|
||||
title={Prices vs. quantities},
|
||||
author={Martin L Weitzman},
|
||||
journal={The review of economic studies},
|
||||
volume={41},
|
||||
number={4},
|
||||
pages={477--491},
|
||||
year={1974},
|
||||
publisher={JSTOR}
|
||||
}
|
||||
|
||||
@misc{bip:141,
|
||||
Author = {Eric Lombrozo, Johnson Lau, and Pieter Wuille},
|
||||
Title = {BIP 141: Segregated Witness},
|
||||
Url = {https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki},
|
||||
Year = {2015},
|
||||
Month = {12},
|
||||
Day = {21}
|
||||
}
|
||||
|
||||
|
||||
|
||||
@book{knight1921risk,
|
||||
title={Risk, uncertainty and profit},
|
||||
author={Knight, Frank H},
|
||||
year={1921},
|
||||
publisher={Courier Corporation}
|
||||
}
|
||||
|
||||
@inproceedings{fc17ai,
|
||||
Title={A Smart Contract for Boardroom Voting with Maximum Voter Privacy},
|
||||
Author={McCorry, Patrick and Shahandashti, Siamak F. and Hao, Feng},
|
||||
Url={http://fc17.ifca.ai/preproceedings/paper_80.pdf},
|
||||
Year={2017},
|
||||
Booktitle={Proceedings of Financial Cryptography and Data Security},
|
||||
Organization={International Financial Cryptography Association}
|
||||
}
|
||||
|
||||
|
||||
@article{vigna13fibonacci,
|
||||
Author = {Sebastiano Vigna},
|
||||
Bibsource = {dblp computer science bibliography, http://dblp.org},
|
||||
Biburl = {http://dblp.uni-trier.de/rec/bib/journals/corr/Vigna13},
|
||||
Journal = {CoRR},
|
||||
Timestamp = {Mon, 06 Jan 2014 15:10:41 +0100},
|
||||
Title = {Fibonacci Binning},
|
||||
Url = {http://arxiv.org/abs/1312.3749},
|
||||
Volume = {abs/1312.3749},
|
||||
Year = {2013},
|
||||
Bdsk-Url-1 = {http://arxiv.org/abs/1312.3749}}
|
||||
|
||||
@misc{wiki:ricochet,
|
||||
Author = {Wikipedia},
|
||||
Note = {[Online; accessed 28-February-2017]},
|
||||
Title = {Ricochet (software) --- Wikipedia{,} The Free Encyclopedia},
|
||||
Url = {https://en.wikipedia.org/w/index.php?title=Ricochet_(software)&oldid=755044411},
|
||||
Year = {2016},
|
||||
Bdsk-Url-1 = {https://en.wikipedia.org/w/index.php?title=Ricochet_(software)&oldid=755044411}}
|
||||
|
||||
@article{darknet,
|
||||
Author = {De Domenico, Manlio and Arenas, Alex},
|
||||
Doi = {10.1103/PhysRevE.95.022313},
|
||||
Issue = {2},
|
||||
Journal = {Phys. Rev. E},
|
||||
Month = {Feb},
|
||||
Numpages = {10},
|
||||
Pages = {022313},
|
||||
Publisher = {American Physical Society},
|
||||
Title = {Modeling structure and resilience of the dark network},
|
||||
Url = {http://link.aps.org/doi/10.1103/PhysRevE.95.022313},
|
||||
Volume = {95},
|
||||
Year = {2017},
|
||||
Bdsk-Url-1 = {http://link.aps.org/doi/10.1103/PhysRevE.95.022313},
|
||||
Bdsk-Url-2 = {http://dx.doi.org/10.1103/PhysRevE.95.022313}}
|
||||
|
||||
@inproceedings{wu2006query,
|
||||
Author = {Wu, Ping and Wen, Ji-Rong and Liu, Huan and Ma, Wei-Ying},
|
||||
Booktitle = {Data Engineering, 2006. ICDE'06. Proceedings of the 22nd International Conference on},
|
||||
Organization = {IEEE},
|
||||
Pages = {47--47},
|
||||
Title = {Query selection techniques for efficient crawling of structured web sources},
|
||||
Year = {2006}}
|
||||
|
||||
@article{borgatti1998network,
|
||||
Author = {Borgatti, Stephen P and Jones, Candace and Everett, Martin G},
|
||||
Journal = {Connections},
|
||||
Number = {2},
|
||||
Pages = {27--36},
|
||||
Title = {Network measures of social capital},
|
||||
Volume = {21},
|
||||
Year = {1998}}
|
||||
|
||||
@misc{wiki:torchat,
|
||||
Author = {Wikipedia},
|
||||
Note = {[Online; accessed 28-February-2017]},
|
||||
Title = {TorChat --- Wikipedia{,} The Free Encyclopedia},
|
||||
Url = {https://en.wikipedia.org/w/index.php?title=TorChat&oldid=728783759},
|
||||
Year = {2016},
|
||||
Bdsk-Url-1 = {https://en.wikipedia.org/w/index.php?title=TorChat&oldid=728783759}}
|
||||
|
||||
@misc{wiki:tormessenger,
|
||||
Author = {Wikipedia},
|
||||
Note = {[Online; accessed 28-February-2017]},
|
||||
Title = {Tor (anonymity network) --- Wikipedia{,} The Free Encyclopedia},
|
||||
Url = {https://en.wikipedia.org/w/index.php?title=Tor_(anonymity_network)#Tor_Messenger&oldid=767770868},
|
||||
Year = {2017},
|
||||
Bdsk-Url-1 = {https://en.wikipedia.org/w/index.php?title=Tor_(anonymity_network)#Tor_Messenger&oldid=767770868}}
|
||||
|
||||
@techreport{pagerank,
|
||||
Abstract = {The importance of a Web page is an inherently subjective matter, which depends on the readers interests, knowledge and attitudes. But there is still much that can be said objectively about the relative importance of Web pages. This paper describes PageRank, a mathod for rating Web pages objectively and mechanically, effectively measuring the human interest and attention devoted to them. We compare PageRank to an idealized random Web surfer. We show how to efficiently compute PageRank for large numbers of pages. And, we show how to apply PageRank to search and to user navigation.},
|
||||
Author = {Lawrence Page and Sergey Brin and Rajeev Motwani and Terry Winograd},
|
||||
Institution = {Stanford InfoLab},
|
||||
Month = {November},
|
||||
Note = {Previous number = SIDL-WP-1999-0120},
|
||||
Number = {1999-66},
|
||||
Publisher = {Stanford InfoLab},
|
||||
Title = {The PageRank Citation Ranking: Bringing Order to the Web.},
|
||||
Type = {Technical Report},
|
||||
Url = {http://ilpubs.stanford.edu:8090/422/},
|
||||
Year = {1999},
|
||||
Bdsk-Url-1 = {http://ilpubs.stanford.edu:8090/422/}}
|
||||
|
||||
@book{everton2012disrupting,
|
||||
Author = {Everton, Sean F},
|
||||
Publisher = {Cambridge University Press},
|
||||
Title = {Disrupting dark networks},
|
||||
Volume = {34},
|
||||
Year = {2012}}
|
||||
|
||||
@article{broder2000graph,
|
||||
Author = {Broder, Andrei and Kumar, Ravi and Maghoul, Farzin and Raghavan, Prabhakar and Rajagopalan, Sridhar and Stata, Raymie and Tomkins, Andrew and Wiener, Janet},
|
||||
Journal = {Computer networks},
|
||||
Number = {1},
|
||||
Pages = {309--320},
|
||||
Publisher = {Elsevier},
|
||||
Title = {Graph structure in the web},
|
||||
Volume = {33},
|
||||
Year = {2000}}
|
||||
|
||||
@article{rfc7686,
|
||||
Author = {Appelbaum, Jacob and Muffet, Alex},
|
||||
Issn = {2070-1721},
|
||||
Journal = {Internet Engineering Task Force RFC},
|
||||
Month = {Oct},
|
||||
Title = {The ``.onion'' Special-Use Domain Name},
|
||||
Url = {https://tools.ietf.org/html/rfc7686},
|
||||
Volume = {7686},
|
||||
Year = {2015},
|
||||
Bdsk-Url-1 = {https://tools.ietf.org/html/rfc7686}}
|
||||
|
||||
@article{clauset2009power,
|
||||
Author = {Clauset, Aaron and Shalizi, Cosma Rohilla and Newman, Mark EJ},
|
||||
Journal = {SIAM review},
|
||||
Number = {4},
|
||||
Pages = {661--703},
|
||||
Publisher = {SIAM},
|
||||
Title = {Power-law distributions in empirical data},
|
||||
Volume = {51},
|
||||
Year = {2009}}
|
||||
|
||||
@article{meusel2015graph,
|
||||
Author = {Meusel, Robert and Vigna, Sebastiano and Lehmberg, Oliver and Bizer, Christian},
|
||||
Journal = {The Journal of Web Science},
|
||||
Number = {1},
|
||||
Title = {The Graph Structure in the Web--Analyzed on Different Aggregation Levels},
|
||||
Volume = {1},
|
||||
Year = {2015}}
|
||||
|
||||
@inproceedings{lehmberg2014graph,
|
||||
Author = {Lehmberg, Oliver and Meusel, Robert and Bizer, Christian},
|
||||
Booktitle = {Proceedings of the 2014 ACM conference on Web science},
|
||||
Organization = {ACM},
|
||||
Pages = {119--128},
|
||||
Title = {Graph structure in the web: aggregated by pay-level domain},
|
||||
Year = {2014}}
|
||||
|
||||
@inproceedings{Meusel2014,
|
||||
Acmid = {2576928},
|
||||
Address = {New York, NY, USA},
|
||||
Author = {Meusel, Robert and Vigna, Sebastiano and Lehmberg, Oliver and Bizer, Christian},
|
||||
Booktitle = {Proceedings of the 23rd International Conference on World Wide Web},
|
||||
Doi = {10.1145/2567948.2576928},
|
||||
Isbn = {978-1-4503-2745-9},
|
||||
Keywords = {graph analysis, network analysis, web graph, web mining, world wide web},
|
||||
Location = {Seoul, Korea},
|
||||
Numpages = {6},
|
||||
Pages = {427--432},
|
||||
Publisher = {ACM},
|
||||
Series = {WWW '14 Companion},
|
||||
Title = {Graph Structure in the Web --- Revisited: A Trick of the Heavy Tail},
|
||||
Url = {http://doi.acm.org/10.1145/2567948.2576928},
|
||||
Year = {2014},
|
||||
Bdsk-Url-1 = {http://doi.acm.org/10.1145/2567948.2576928},
|
||||
Bdsk-Url-2 = {http://dx.doi.org/10.1145/2567948.2576928}}
|
||||
|
||||
@article{Serrano2007,
|
||||
Acmid = {1255442},
|
||||
Address = {New York, NY, USA},
|
||||
Articleno = {10},
|
||||
Author = {Serrano, M. \'{A}ngeles and Maguitman, Ana and Bogu\~{n}\'{a}, Mari\'{a}n and Fortunato, Santo and Vespignani, Alessandro},
|
||||
Doi = {10.1145/1255438.1255442},
|
||||
Issn = {1559-1131},
|
||||
Issue_Date = {August 2007},
|
||||
Journal = {ACM Trans. Web},
|
||||
Keywords = {Web graph structure, Web measurement, crawler biases, statistical analysis},
|
||||
Month = aug,
|
||||
Number = {2},
|
||||
Publisher = {ACM},
|
||||
Title = {Decoding the Structure of the WWW: A Comparative Analysis of Web Crawls},
|
||||
Url = {http://doi.acm.org/10.1145/1255438.1255442},
|
||||
Volume = {1},
|
||||
Year = {2007},
|
||||
Bdsk-Url-1 = {http://doi.acm.org/10.1145/1255438.1255442},
|
||||
Bdsk-Url-2 = {http://dx.doi.org/10.1145/1255438.1255442}}
|
||||
|
||||
@inproceedings{li2004first,
|
||||
Author = {Li, Lun and Alderson, David and Willinger, Walter and Doyle, John},
|
||||
Booktitle = {ACM SIGCOMM Computer Communication Review},
|
||||
Number = {4},
|
||||
Organization = {ACM},
|
||||
Pages = {3--14},
|
||||
Title = {A first-principles approach to understanding the internet's router-level topology},
|
||||
Volume = {34},
|
||||
Year = {2004}}
|
||||
|
||||
@article{bollobas2004robustness,
|
||||
Author = {Bollob{\'a}s, B{\'e}la and Riordan, Oliver},
|
||||
Journal = {Internet Mathematics},
|
||||
Number = {1},
|
||||
Pages = {1--35},
|
||||
Publisher = {Taylor \& Francis},
|
||||
Title = {Robustness and vulnerability of scale-free random graphs},
|
||||
Volume = {1},
|
||||
Year = {2004}}
|
||||
|
||||
@article{barabasi1999emergence,
|
||||
Author = {Barab{\'a}si, Albert-L{\'a}szl{\'o} and Albert, R{\'e}ka},
|
||||
Journal = {science},
|
||||
Number = {5439},
|
||||
Pages = {509--512},
|
||||
Publisher = {American Association for the Advancement of Science},
|
||||
Title = {Emergence of scaling in random networks},
|
||||
Volume = {286},
|
||||
Year = {1999}}
|
||||
|
||||
@article{willinger2013internet,
|
||||
Author = {Willinger, Walter and Roughan, Matthew},
|
||||
Journal = {ACM SIGCOMM eBook: Recent Advances in Networking},
|
||||
Title = {Internet topology research redux},
|
||||
Year = {2013}}
|
||||
|
||||
@article{willinger2009mathematics,
|
||||
Author = {Willinger, Walter and Alderson, David and Doyle, John C},
|
||||
Journal = {Notices of the AMS},
|
||||
Number = {5},
|
||||
Pages = {586--599},
|
||||
Title = {Mathematics and the internet: A source of enormous confusion and great potential},
|
||||
Volume = {56},
|
||||
Year = {2009}}
|
||||
|
||||
@article{pansiot1998routes,
|
||||
Author = {Pansiot, Jean-Jacques and Grad, Dominique},
|
||||
Journal = {ACM SIGCOMM Computer Communication Review},
|
||||
Number = {1},
|
||||
Pages = {41--50},
|
||||
Publisher = {ACM},
|
||||
Title = {On routes and multicast trees in the Internet},
|
||||
Volume = {28},
|
||||
Year = {1998}}
|
||||
|
||||
@mastersthesis{jovanovic2001modeling,
|
||||
Author = {Jovanovic, Mihajlo A},
|
||||
School = {University of Cincinnati},
|
||||
Title = {Modeling large-scale peer-to-peer networks and a case study of Gnutella},
|
||||
Year = {2001}}
|
||||
|
||||
@inproceedings{kumar2000web,
|
||||
Author = {Kumar, Ravi and Raghavan, Prabhakar and Rajagopalan, Sridhar and Sivakumar, Dandapani and Tompkins, Andrew and Upfal, Eli},
|
||||
Booktitle = {Proceedings of the nineteenth ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems},
|
||||
Organization = {ACM},
|
||||
Pages = {1--10},
|
||||
Title = {The Web as a graph},
|
||||
Year = {2000}}
|
||||
|
||||
@article{barabasi2000scale,
|
||||
Author = {Barab{\'a}si, Albert-L{\'a}szl{\'o} and Albert, R{\'e}ka and Jeong, Hawoong},
|
||||
Journal = {Physica A: Statistical Mechanics and its Applications},
|
||||
Number = {1},
|
||||
Pages = {69--77},
|
||||
Publisher = {Elsevier},
|
||||
Title = {Scale-free characteristics of random networks: the topology of the world-wide web},
|
||||
Volume = {281},
|
||||
Year = {2000}}
|
||||
|
||||
@article{siganos2003power,
|
||||
Author = {Siganos, Georgos and Faloutsos, Michalis and Faloutsos, Petros and Faloutsos, Christos},
|
||||
Journal = {IEEE/ACM Transactions on Networking (TON)},
|
||||
Number = {4},
|
||||
Pages = {514--524},
|
||||
Publisher = {IEEE Press},
|
||||
Title = {Power laws and the AS-level internet topology},
|
||||
Volume = {11},
|
||||
Year = {2003}}
|
||||
|
||||
@inproceedings{biryukov2013trawling,
|
||||
Author = {Biryukov, Alex and Pustogarov, Ivan and Weinmann, Ralf-Philipp},
|
||||
Booktitle = {Security and Privacy (SP), 2013 IEEE Symposium on},
|
||||
Organization = {IEEE},
|
||||
Pages = {80--94},
|
||||
Title = {Trawling for tor hidden services: Detection, measurement, deanonymization},
|
||||
Year = {2013}}
|
||||
|
||||
@article{albert2001physics,
|
||||
Author = {Albert-L{\'a}szl{\'o} Barab{\'a}si, July},
|
||||
Journal = {Physics Web http://www.physicsweb.org/article/world/14/7/09},
|
||||
Title = {The physics of the Web},
|
||||
Year = {2001}}
|
||||
|
||||
@article{cohen2001breakdown,
|
||||
Author = {Cohen, Reuven and Erez, Keren and Ben-Avraham, Daniel and Havlin, Shlomo},
|
||||
Journal = {Physical review letters},
|
||||
Number = {16},
|
||||
Pages = {3682},
|
||||
Publisher = {APS},
|
||||
Title = {Breakdown of the Internet under intentional attack},
|
||||
Volume = {86},
|
||||
Year = {2001}}
|
||||
|
||||
@article{albert2000error,
|
||||
Author = {Albert, R{\'e}ka and Jeong, Hawoong and Barab{\'a}si, Albert-L{\'a}szl{\'o}},
|
||||
Journal = {nature},
|
||||
Number = {6794},
|
||||
Pages = {378--382},
|
||||
Publisher = {Nature Publishing Group},
|
||||
Title = {Error and attack tolerance of complex networks},
|
||||
Volume = {406},
|
||||
Year = {2000}}
|
||||
|
||||
@article{adamic2000power,
|
||||
Author = {Adamic, Lada A and Huberman, Bernardo A},
|
||||
Journal = {Science},
|
||||
Number = {5461},
|
||||
Pages = {2115--2115},
|
||||
Publisher = {American Association for the Advancement of Science},
|
||||
Title = {Power-law distribution of the world wide web},
|
||||
Volume = {287},
|
||||
Year = {2000}}
|
||||
|
||||
@misc{tormetrics,
|
||||
Author = {The Tor Project},
|
||||
Month = {January},
|
||||
Title = {TorMetrics --- Unique .onion addresses},
|
||||
Url = {https://metrics.torproject.org/hidserv-dir-onions-seen.html},
|
||||
Year = {2017},
|
||||
Bdsk-Url-1 = {https://metrics.torproject.org/hidserv-dir-onions-seen.html}}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 319 KiB |
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 133 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
|
@ -0,0 +1,236 @@
|
|||
%%%% NIPS Macros (LaTex)
|
||||
%%%% Style File
|
||||
%%%% Dec 12, 1990 Rev Aug 14, 1991; Sept, 1995; April, 1997; April, 1999
|
||||
|
||||
% This file can be used with Latex2e whether running in main mode, or
|
||||
% 2.09 compatibility mode.
|
||||
%
|
||||
% If using main mode, you need to include the commands
|
||||
% \documentclass{article}
|
||||
% \usepackage{nips10submit_e,times}
|
||||
% as the first lines in your document. Or, if you do not have Times
|
||||
% Roman font available, you can just use
|
||||
% \documentclass{article}
|
||||
% \usepackage{nips10submit_e}
|
||||
% instead.
|
||||
%
|
||||
% If using 2.09 compatibility mode, you need to include the command
|
||||
% \documentstyle[nips10submit_09,times]{article}
|
||||
% as the first line in your document. Or, if you do not have Times
|
||||
% Roman font available, you can include the command
|
||||
% \documentstyle[nips10submit_09]{article}
|
||||
% instead.
|
||||
|
||||
% Change the overall width of the page. If these parameters are
|
||||
% changed, they will require corresponding changes in the
|
||||
% maketitle section.
|
||||
%
|
||||
\usepackage{eso-pic} % used by \AddToShipoutPicture
|
||||
|
||||
\renewcommand{\topfraction}{0.95} % let figure take up nearly whole page
|
||||
\renewcommand{\textfraction}{0.05} % let figure take up nearly whole page
|
||||
|
||||
% Define nipsfinal, set to true if nipsfinalcopy is defined
|
||||
\newif\ifnipsfinal
|
||||
\nipsfinalfalse
|
||||
\def\nipsfinalcopy{\nipsfinaltrue}
|
||||
\font\nipstenhv = phvb at 8pt % *** IF THIS FAILS, SEE nips10submit_e.sty ***
|
||||
|
||||
% Specify the dimensions of each page
|
||||
|
||||
\setlength{\paperheight}{11in}
|
||||
\setlength{\paperwidth}{8.5in}
|
||||
|
||||
\oddsidemargin .5in % Note \oddsidemargin = \evensidemargin
|
||||
\evensidemargin .5in
|
||||
\marginparwidth 0.07 true in
|
||||
%\marginparwidth 0.75 true in
|
||||
%\topmargin 0 true pt % Nominal distance from top of page to top of
|
||||
%\topmargin 0.125in
|
||||
\topmargin -0.625in
|
||||
\addtolength{\headsep}{0.25in}
|
||||
\textheight 9.0 true in % Height of text (including footnotes & figures)
|
||||
\textwidth 5.5 true in % Width of text line.
|
||||
\widowpenalty=10000
|
||||
\clubpenalty=10000
|
||||
|
||||
% \thispagestyle{empty} \pagestyle{empty}
|
||||
\flushbottom \sloppy
|
||||
|
||||
% We're never going to need a table of contents, so just flush it to
|
||||
% save space --- suggested by drstrip@sandia-2
|
||||
\def\addcontentsline#1#2#3{}
|
||||
|
||||
% Title stuff, taken from deproc.
|
||||
\def\maketitle{\par
|
||||
\begingroup
|
||||
\def\thefootnote{\fnsymbol{footnote}}
|
||||
\def\@makefnmark{\hbox to 0pt{$^{\@thefnmark}$\hss}} % for perfect author
|
||||
% name centering
|
||||
% The footnote-mark was overlapping the footnote-text,
|
||||
% added the following to fix this problem (MK)
|
||||
\long\def\@makefntext##1{\parindent 1em\noindent
|
||||
\hbox to1.8em{\hss $\m@th ^{\@thefnmark}$}##1}
|
||||
\@maketitle \@thanks
|
||||
\endgroup
|
||||
\setcounter{footnote}{0}
|
||||
\let\maketitle\relax \let\@maketitle\relax
|
||||
\gdef\@thanks{}\gdef\@author{}\gdef\@title{}\let\thanks\relax}
|
||||
|
||||
% The toptitlebar has been raised to top-justify the first page
|
||||
|
||||
% Title (includes both anonimized and non-anonimized versions)
|
||||
\def\@maketitle{\vbox{\hsize\textwidth
|
||||
\linewidth\hsize \vskip 0.1in \toptitlebar \centering
|
||||
{\LARGE\bf \@title\par} \bottomtitlebar % \vskip 0.1in % minus
|
||||
\ifnipsfinal
|
||||
\def\And{\end{tabular}\hfil\linebreak[0]\hfil
|
||||
\begin{tabular}[t]{c}\bf\rule{\z@}{24pt}\ignorespaces}%
|
||||
\def\AND{\end{tabular}\hfil\linebreak[4]\hfil
|
||||
\begin{tabular}[t]{c}\bf\rule{\z@}{24pt}\ignorespaces}%
|
||||
\begin{tabular}[t]{c}\bf\rule{\z@}{24pt}\@author\end{tabular}%
|
||||
\else
|
||||
\begin{tabular}[t]{c}\bf\rule{\z@}{24pt}
|
||||
Anonymous Author(s) \\
|
||||
Affiliation \\
|
||||
Address \\
|
||||
\texttt{email} \\
|
||||
\end{tabular}%
|
||||
\fi
|
||||
\vskip 0.3in minus 0.1in}}
|
||||
|
||||
\renewenvironment{abstract}{\vskip.075in\centerline{\large\bf
|
||||
Abstract}\vspace{0.5ex}\begin{quote}}{\par\end{quote}\vskip 1ex}
|
||||
|
||||
% sections with less space
|
||||
\def\section{\@startsection {section}{1}{\z@}{-2.0ex plus
|
||||
-0.5ex minus -.2ex}{1.5ex plus 0.3ex
|
||||
minus0.2ex}{\large\bf\raggedright}}
|
||||
|
||||
\def\subsection{\@startsection{subsection}{2}{\z@}{-1.8ex plus
|
||||
-0.5ex minus -.2ex}{0.8ex plus .2ex}{\normalsize\bf\raggedright}}
|
||||
\def\subsubsection{\@startsection{subsubsection}{3}{\z@}{-1.5ex
|
||||
plus -0.5ex minus -.2ex}{0.5ex plus
|
||||
.2ex}{\normalsize\bf\raggedright}}
|
||||
\def\paragraph{\@startsection{paragraph}{4}{\z@}{1.5ex plus
|
||||
0.5ex minus .2ex}{-1em}{\normalsize\bf}}
|
||||
\def\subparagraph{\@startsection{subparagraph}{5}{\z@}{1.5ex plus
|
||||
0.5ex minus .2ex}{-1em}{\normalsize\bf}}
|
||||
\def\subsubsubsection{\vskip
|
||||
5pt{\noindent\normalsize\rm\raggedright}}
|
||||
|
||||
|
||||
% Footnotes
|
||||
\footnotesep 6.65pt %
|
||||
\skip\footins 9pt plus 4pt minus 2pt
|
||||
\def\footnoterule{\kern-3pt \hrule width 12pc \kern 2.6pt }
|
||||
\setcounter{footnote}{0}
|
||||
|
||||
% Lists and paragraphs
|
||||
\parindent 0pt
|
||||
\topsep 4pt plus 1pt minus 2pt
|
||||
\partopsep 1pt plus 0.5pt minus 0.5pt
|
||||
\itemsep 2pt plus 1pt minus 0.5pt
|
||||
\parsep 2pt plus 1pt minus 0.5pt
|
||||
\parskip .5pc
|
||||
|
||||
|
||||
%\leftmargin2em
|
||||
\leftmargin3pc
|
||||
\leftmargini\leftmargin \leftmarginii 2em
|
||||
\leftmarginiii 1.5em \leftmarginiv 1.0em \leftmarginv .5em
|
||||
|
||||
%\labelsep \labelsep 5pt
|
||||
|
||||
\def\@listi{\leftmargin\leftmargini}
|
||||
\def\@listii{\leftmargin\leftmarginii
|
||||
\labelwidth\leftmarginii\advance\labelwidth-\labelsep
|
||||
\topsep 2pt plus 1pt minus 0.5pt
|
||||
\parsep 1pt plus 0.5pt minus 0.5pt
|
||||
\itemsep \parsep}
|
||||
\def\@listiii{\leftmargin\leftmarginiii
|
||||
\labelwidth\leftmarginiii\advance\labelwidth-\labelsep
|
||||
\topsep 1pt plus 0.5pt minus 0.5pt
|
||||
\parsep \z@ \partopsep 0.5pt plus 0pt minus 0.5pt
|
||||
\itemsep \topsep}
|
||||
\def\@listiv{\leftmargin\leftmarginiv
|
||||
\labelwidth\leftmarginiv\advance\labelwidth-\labelsep}
|
||||
\def\@listv{\leftmargin\leftmarginv
|
||||
\labelwidth\leftmarginv\advance\labelwidth-\labelsep}
|
||||
\def\@listvi{\leftmargin\leftmarginvi
|
||||
\labelwidth\leftmarginvi\advance\labelwidth-\labelsep}
|
||||
|
||||
\abovedisplayskip 7pt plus2pt minus5pt%
|
||||
\belowdisplayskip \abovedisplayskip
|
||||
\abovedisplayshortskip 0pt plus3pt%
|
||||
\belowdisplayshortskip 4pt plus3pt minus3pt%
|
||||
|
||||
% Less leading in most fonts (due to the narrow columns)
|
||||
% The choices were between 1-pt and 1.5-pt leading
|
||||
%\def\@normalsize{\@setsize\normalsize{11pt}\xpt\@xpt} % got rid of @ (MK)
|
||||
\def\normalsize{\@setsize\normalsize{11pt}\xpt\@xpt}
|
||||
\def\small{\@setsize\small{10pt}\ixpt\@ixpt}
|
||||
\def\footnotesize{\@setsize\footnotesize{10pt}\ixpt\@ixpt}
|
||||
\def\scriptsize{\@setsize\scriptsize{8pt}\viipt\@viipt}
|
||||
\def\tiny{\@setsize\tiny{7pt}\vipt\@vipt}
|
||||
\def\large{\@setsize\large{14pt}\xiipt\@xiipt}
|
||||
\def\Large{\@setsize\Large{16pt}\xivpt\@xivpt}
|
||||
\def\LARGE{\@setsize\LARGE{20pt}\xviipt\@xviipt}
|
||||
\def\huge{\@setsize\huge{23pt}\xxpt\@xxpt}
|
||||
\def\Huge{\@setsize\Huge{28pt}\xxvpt\@xxvpt}
|
||||
|
||||
\def\toptitlebar{\hrule height4pt\vskip .25in\vskip-\parskip}
|
||||
|
||||
\def\bottomtitlebar{\vskip .29in\vskip-\parskip\hrule height1pt\vskip
|
||||
.09in} %
|
||||
%Reduced second vskip to compensate for adding the strut in \@author
|
||||
|
||||
% Vertical Ruler
|
||||
% This code is, largely, from the CVPR 2010 conference style file
|
||||
% ----- define vruler
|
||||
\makeatletter
|
||||
\newbox\nipsrulerbox
|
||||
\newcount\nipsrulercount
|
||||
\newdimen\nipsruleroffset
|
||||
\newdimen\cv@lineheight
|
||||
\newdimen\cv@boxheight
|
||||
\newbox\cv@tmpbox
|
||||
\newcount\cv@refno
|
||||
\newcount\cv@tot
|
||||
% NUMBER with left flushed zeros \fillzeros[<WIDTH>]<NUMBER>
|
||||
\newcount\cv@tmpc@ \newcount\cv@tmpc
|
||||
\def\fillzeros[#1]#2{\cv@tmpc@=#2\relax\ifnum\cv@tmpc@<0\cv@tmpc@=-\cv@tmpc@\fi
|
||||
\cv@tmpc=1 %
|
||||
\loop\ifnum\cv@tmpc@<10 \else \divide\cv@tmpc@ by 10 \advance\cv@tmpc by 1 \fi
|
||||
\ifnum\cv@tmpc@=10\relax\cv@tmpc@=11\relax\fi \ifnum\cv@tmpc@>10 \repeat
|
||||
\ifnum#2<0\advance\cv@tmpc1\relax-\fi
|
||||
\loop\ifnum\cv@tmpc<#1\relax0\advance\cv@tmpc1\relax\fi \ifnum\cv@tmpc<#1 \repeat
|
||||
\cv@tmpc@=#2\relax\ifnum\cv@tmpc@<0\cv@tmpc@=-\cv@tmpc@\fi \relax\the\cv@tmpc@}%
|
||||
% \makevruler[<SCALE>][<INITIAL_COUNT>][<STEP>][<DIGITS>][<HEIGHT>]
|
||||
\def\makevruler[#1][#2][#3][#4][#5]{\begingroup\offinterlineskip
|
||||
\textheight=#5\vbadness=10000\vfuzz=120ex\overfullrule=0pt%
|
||||
\global\setbox\nipsrulerbox=\vbox to \textheight{%
|
||||
{\parskip=0pt\hfuzz=150em\cv@boxheight=\textheight
|
||||
\cv@lineheight=#1\global\nipsrulercount=#2%
|
||||
\cv@tot\cv@boxheight\divide\cv@tot\cv@lineheight\advance\cv@tot2%
|
||||
\cv@refno1\vskip-\cv@lineheight\vskip1ex%
|
||||
\loop\setbox\cv@tmpbox=\hbox to0cm{{\nipstenhv\hfil\fillzeros[#4]\nipsrulercount}}%
|
||||
\ht\cv@tmpbox\cv@lineheight\dp\cv@tmpbox0pt\box\cv@tmpbox\break
|
||||
\advance\cv@refno1\global\advance\nipsrulercount#3\relax
|
||||
\ifnum\cv@refno<\cv@tot\repeat}}\endgroup}%
|
||||
\makeatother
|
||||
% ----- end of vruler
|
||||
|
||||
% \makevruler[<SCALE>][<INITIAL_COUNT>][<STEP>][<DIGITS>][<HEIGHT>]
|
||||
\def\nipsruler#1{\makevruler[12pt][#1][1][3][0.993\textheight]\usebox{\nipsrulerbox}}
|
||||
\AddToShipoutPicture{%
|
||||
\ifnipsfinal\else
|
||||
\nipsruleroffset=\textheight
|
||||
\advance\nipsruleroffset by -3.7pt
|
||||
\color[rgb]{.7,.7,.7}
|
||||
\AtTextUpperLeft{%
|
||||
\put(\LenToUnit{-35pt},\LenToUnit{-\nipsruleroffset}){%left ruler
|
||||
\nipsruler{\nipsrulercount}}
|
||||
}
|
||||
\fi
|
||||
}
|
||||
Loading…
Reference in New Issue