text:
\section{Introduction}
\label{sec:intro}

A \emph{blockchain} is an append-only, secure, transparent, distributed ledger. It stores the data in \emph{blocks} connected through immutable cryptographic links, with each block extending exactly one previous block.
Introduced in Bitcoin \cite{nakamoto2008bitcoin}, blockchain is one of the most significant technological innovations of this century.
The underlying technical problem that Bitcoin solves through blockchain is \emph{byzantine fault tolerant} \emph{distributed consensus} in a decentralized system.

In any blockchain system,
delays in communication and adversarial attacks may cause \emph{forks} in the chain, creating ambiguity as to extend which block. In summary, (i) to prevent forks, we require that only one \emph{node} publish a block at a time. Thus, we need a \emph{distributed mechanism}, which we refer to as \emph{block publisher selection mechanism} (BPSM) to select a node as \emph{selected block publisher} (SBP). (ii) Still, if forks occur, to resolve them,  we require the protocol to specify a \emph{chain selection rule} (CSR). The BPSM and CSR functionally characterize a blockchain protocol.
Typically, we measure a blockchain's performance with the two metrics: i) \emph{transactions per second} ($tps$), and ii) \emph{time for finality} ($t_f$), i.e., the time required to confirm a transaction.

Bitcoin blockchain protocol uses a \emph{Proof-of-Work} (PoW) based BPSM and \emph{longest chain} as the CSR. In the PoW mechanism, each node has a different cryptographic puzzle to solve, of the same level of difficulty. Once a node solves the puzzle, it publishes the block, i.e., proposes the block to be added to the chain. The rest of the nodes verify and add the first valid block they receive to their blockchain. Block rewards and transaction fees serve as incentives for nodes to participate and follow the protocol.
Bitcoin, though a great innovation, has certain challenges when it comes to efficiency and performance. Bitcoin consumes a high amount of electrical power to function. As of writing this paper, the Bitcoin network uses an estimated $138\times10^{3}$ Peta hashes per second \cite{bitinfocharts} and annual power consumption of $70$ TWh \cite{digiconomist}.  Typically in Bitcoin $tps=4$ and $t_f=60$ minutes \cite{blockchain.com}. Due to the poor $tps$, it is unable to scale to high volumes, and the high $t_f$ deters usability and adoption.
Attempts such as \emph{GHOST} \cite{sompolinsky2013accelerating} aim to improve the performance by using a different CSR. In GHOST, the BPSM being still PoW-based, its power consumption remains high. Towards addressing high power consumption, researchers proposed \emph{Proof-of-Stake} (PoS) based BPSM.

PoS based blockchain protocols, such as Algorand \cite{gilad2017algorand} and Casper \cite{buterin2017casper}, stochastically select an SBP with probability proportional to its \emph{relative stake}. This approach is also consistent with the expectation that nodes that are stakeholders would not want to endanger the system. The \emph{Ouroboros} protocols \cite{kiayias2017ouroboros,david2018ouroboros,badertscher2018ouroboros,kerber2018ouroboros} are popular PoS-based protocols, amongst others. Ouroboros is not only academically published\footnote{Some PoS protocols are not academically published, e.g. Casper} in a peer-reviewed forum, but also is the foundation for the crypto-currency \emph{Cardano} \cite{cardano}.

\emph{Ouroboros v1} (v1) \cite{kiayias2017ouroboros} achieves high $tps$ and better $t_f$ than Bitcoin. However, for a blockchain protocol to be completely secure, it must be immune to \emph{fully adaptive corruption}s (FACs), i.e., a \emph{dynamic adversary}. Ouroboros v1 is not immune to FACs.
\emph{Ouroboros Praos} (Praos) \cite{david2018ouroboros} uses a different BPSM. Praos does solve the security weakness, but does not improve performance. While both \emph{Ouroboros Genesis} \cite{badertscher2018ouroboros} and \emph{Ouroboros Crypsinous} \cite{kerber2018ouroboros} protocols enhance the Ouroboros protocol, they too do not improve performance.

In this work, we propose a novel blockchain protocol, \emph{QuickSync}\ that is secure against FACs, and achieves slightly better $tps$, and improves on the $t_f$ by a factor of 3, as compared to Ouroboros v1. Essentially, it quickly synchronizes (resolves) the forks that arise. To build \emph{QuickSync}, we employ the framework of the Ouroboros protocol. \emph{QuickSync}\ differs from v1 and Praos, in both the BPSM and the CSR.
The key idea is, we propose a metric called \emph{block power}, assigned to each block. With this, we compute \emph{chain power} of every competing chain. The chain power of a chain is the sum of block powers of all the blocks of the chain. Using chain powers, we establish the \emph{best chain}, the one with the highest value for this metric, that the node must build on from a given set of chains. It results in ensuring that all forks are trivially resolved, except for the ones generated by the adversary. Block power is a function of the output of the node's privately computed \emph{Verifiable Random Function} (VRF) output based on the digital signature of the node, seed randomness, and the slot counter. The VRF output is not revealed until the block is published, enabling immunity against Fully Adaptive Corruptions. Block power is also a function of the relative stake that the node holds to enable the PoS aspect of the mechanism. A naive implementation of such a concept is vulnerable to Sybil attacks. To solve this, we present a \emph{Sybil attack resistant function}, which we utilize for the block power metric, with the help of a technique called \emph{histogram matching}.

As multiple nodes publish blocks at the same time, it may seem that there will be several forks in \emph{QuickSync}, as is the case in the other PoS protocols such as Praos. The key novelty here is that we resolve these forks immediately using block power rather than relying on the network to eventually resolve them using the longest chain CSR. Thus, \emph{QuickSync}\ is in sharp contrast to other PoS-based mechanisms that \emph{do not differentiate} between the published blocks.

Researchers showed that any blockchain protocol satisfying the three properties: \emph{common-prefix}, \emph{chain-growth}, and \emph{chain-quality} implements a robust transaction ledger  \cite{garay2015bitcoin,kiayias2015speed,pass2017analysis}. We prove that \emph{QuickSync}\ satisfies these three properties (Theorem \ref{theo:sr}) and ascertain that our protocol is immune to FACs (Proposition \ref{prop:fac}). We also examine our protocol for different attack strategies and show resistance to them. In summary, the PoS-based blockchain protocol, \emph{QuickSync}\ fixes the security weakness of Ouroboros v1 while improving on performance and performs better in terms of $tps$ and $t_f$ by about an order of magnitude as compared to Bitcoin.

The rest of the paper is organized as follows. In Section \ref{sec:rel}, we summarize the related work in this domain. In Section \ref{sec:prelim}, we explain the relevant preliminaries. In Section \ref{sec:ourproto}, we describe our protocol, \emph{QuickSync}. In Section \ref{ssec:op_oa} we discuss the intuition behind \emph{QuickSync}. Finally, we discuss how to set the parameters for \emph{QuickSync}\ in Section \ref{sec:disc} and conclude the paper in Section \ref{sec:conc}. The detailed security analysis, analysis of attack strategies, and a comparative note are provided in the Appendix.

\section{Related Work}
\label{sec:rel}

\paragraph*{Bitcoin Protocol}
Bitcoin's popularity has attracted much research on this subject. Analysis of the functioning of the Bitcoin protocol, in \cite{garay2015bitcoin,pass2017analysis}, provides a fundamental understanding of how it implements a robust transaction ledger, while a study of Bitcoin from a game-theoretic perspective, such as in \cite{lewenberg2015bitcoin,kwon2019bitcoin}, provides insight into the realistic operation. The vulnerabilities of the protocol are well explored in works such as \cite{eyal2018majority,carlsten2016instability,zhang2019lay,apostolaki2017hijacking}. There have been several efforts to improve the Bitcoin protocol, such as the one discussed in \cite{sompolinsky2013accelerating}. There is also much research based on utilizing blockchain technology for different purposes, as discussed in \cite{dziembowski2019perun,tomescu2017catena,mauw2018distance}.

\paragraph*{PoS-based Protocols}
As pointed out in the Introduction, to maintain Bitcoin, the nodes consume a large amount of power due to PoW-based BPSM. To avoid this massive power consumption, researchers explored alternative modes of mining currencies. PoS has been one of the most popular such modes.
There have been several approaches to PoS-based protocols apart from the Ouroboros protocol, such as; \emph{PPcoin} \cite{king2012ppcoin}, which uses coin age along with PoS and PoW; Ethereum's \emph{Casper} protocol \cite{buterin2017casper}, that uses validators that lose their stake when they behave maliciously; \emph{Snow White} protocol \cite{bentov2016snow}, that too uses epochs and is provably secure; \emph{Algorand} protocol \cite{gilad2017algorand}, that uses \emph{Byzantine Fault Tolerant} mechanisms to achieve consensus and is also provably secure, though it requires $\frac{2}{3}$ majority of honest nodes.

Apart from independent protocols, there has been significant research on concepts that could potentially improve or augment PoS protocols. Ouroboros Crypsinous \cite{kerber2018ouroboros} already utilizes one such technology, \emph{Zerocash} \cite{sasson2014zerocash}, to provide privacy. PoS protocols could also use \emph{context-sensitive transactions} \cite{larimer2013transactions,larimer2018delegated} as discussed in \cite{gavzi2018stake} to do without moving checkpoints. Efforts such as \emph{Scalable Bias-Resistant Distributed Randomness} \cite{syta2017scalable}, could aid in improving the randomness beacons used in PoS protocols. Concepts such as, sharding as demonstrated in \emph{Omni-Ledger} \cite{kokoris2018omniledger}, and \emph{Proof-of-Stake Sidechains} \cite{gazi2019proof}, could potentially be applied to scale the throughput of blockchains.

\section{Preliminaries}
\label{sec:prelim}
In this section, we discuss the preliminary notions and key concepts required to build \emph{QuickSync}.
\subsection{General Concepts and Notation}
\label{ssec:notation}

\subsubsection{Blockchain}
A blockchain is a singular sequence of blocks connected by hash links, with each block linked to the last, starting from the genesis block. The genesis block enlists the initialization specifics and parameters of the blockchain.
A block is comprised of a \emph{block header} and \emph{block data}. The block header contains, amongst other things, the publisher's public key and the hash of the \emph{merkle tree root} of the block data, as well as the hash of the previous block. The block data contains the transactions or any other data that is to be added to the record. \emph{Block publisher} is the node that has built the block in consideration. We refer to the number of transactions per block as $tpb$.
A chain of blocks, $C$ referred to as chain, consists of an ordered set of blocks, where every block, $B^l; l>0$ is immutably linked to the block, $B^{l-1}$, $\forall B^l \in C$; where $l$ represents the ordinal number, and $B^0$ is the genesis block. The length of a chain, $C$, is denoted as $len(C)$, is the number of blocks in the chain excluding the genesis block. We say that the chain selected by the CSR has been \emph{adopted} and is \emph{held} by the node.

\subsubsection{Blockchain Protocol}
Typically a collection of independent, autonomous, distributed nodes are participants in maintaining a blockchain, and they need a blockchain protocol for the same. We start by describing the key concepts to build any blockchain protocol. Each node is identified by a public key $pk$ and holds a master secret key $msk$. $\mathbb{S}$ is the set of all nodes, composed of $\mathbb{H}$, the set of all honest nodes (motivated by reward schemes) and, $\mathbb{A}$, the adversary.

Blockchain being a decentralized system, to propose a new block, we need to select the publisher for each block. We call the publisher \emph{selected block publisher} (SBP).
As multiple nodes from $\mathbb{S}$ would be interested in writing the next block, we need \emph{block publisher selection mechanism} (BPSM) to select an SBP. Due to network delays and adversarial attacks, it is possible to have multiple versions of the chains, i.e., forks from the previously agreed state of the chain. While designing a blockchain protocol, there should be an implicit or explicit rule to resolve these forks. We refer to this as \emph{chain selection rule} (CSR). In summary, to design a blockchain protocol, we need to specify BPSM and CSR. For example, in \emph{Bitcoin}, the BPSM used is PoW (whoever solves the cryptographic puzzle first), and the CSR used is \emph{longest chain}.

\subsubsection{Proof-of-Stake Blockchain Protocols}
In \emph{Proof-of-Stake} (PoS) protocols, each node $n \in \mathbb{S}$ has influence proportional to the amount of \emph{relative stake} it holds. This influence is expressed as the probability of being selected as an SBP.
The fraction of the total stake held by the nodes in consideration is referred to as \emph{relative stake}. $r_h$ and $r_a$ denotes the relative stake of the honest nodes and the adversary respectively ($r_h,r_a \geq 0$, $r_h + r_a = 1$).
The relative stake that is active and participates in the execution of the protocol at any given moment is represented as $r^{active}\geq 0$.

\subsubsection{Forks}
A \emph{fork} in a blockchain is the case when two different blocks extend the same block. Forks happen when two or more honest nodes publish blocks in temporal vicinity, close enough not to have heard of the other's blocks (due to network delay). Forks cause multiple possible valid blocks that can be extended. The adversary could also attempt to create a fork, privately or publicly, to compromise the protocol intentionally. These forks enable an adversary to double spend. An essential part of blockchain protocols is to ensure that these forks are resolved with increasing (preferably exponential) probability as the protocol executes, thus enabling relative finality with time.

\subsubsection{Relative Finality} To establish \emph{relative finality}, we define \emph{k-finality} (referred to as finality) as the property of a blockchain protocol. We say the protocol has finality with parameter $k$, if all the honest nodes can confirm a block $B$, once $k$ valid blocks have extended the chain after block $B$. Similar to Bitcoin and Ouroboros, we establish relative finality, i.e., the confirmation of a block by an honest node implies that with probability $1-\eta$ ($0<\eta<1$), no other honest node will ever in the future disagree with the confirmed block's placement in the ledger.

To violate k-finality, the adversary must show a chain, $C'$, that makes the honest nodes replace their CSR selected chain, $C$, where $C$ and $C'$ differ by at least $k$ blocks.

\subsubsection{Performance metrics} We define \emph{transactions per second} ($tps$) of a protocol, as the maximum number of transactions that the protocol can add to its record every second.
We define \emph{time to finality} ($t_f$) as the time it takes for the protocol to confirm a block once published, given a certain required assurance level of $1-\eta$, $0<\eta<1$. Please note that $t_f=k\cdot t_{sl}$, where $k$ is the \emph{common prefix parameter} and $t_{sl}$ is the slot length in units of time.

\subsubsection{Requisites for a Consensus of a Blockchain Protocol}
\label{ssec:reqbp}
A blockchain is, in essence, a transaction ledger. For a protocol to implement a robust transaction ledger, it must satisfy two properties \cite{garay2015bitcoin}:
\begin{itemize}
    \item \emph{liveness}: Once a node broadcasts a transaction, it will eventually be included in the transaction ledger and be confirmed.
    \item \emph{persistence}: Once an honest node confirms a transaction, then all the other honest nodes, when queried, will agree with its placement in the ledger.
\end{itemize}

The authors of \cite{kiayias2015speed,pass2017analysis} showed that liveness and persistence are equivalent to \emph{common prefix}, \emph{chain growth} and, \emph{chain quality} for any blockchain protocol.
For a PoS-based blockchain protocol that utilizes slots, these three properties are defined as follows in \cite{kiayias2017ouroboros}.
\begin{itemize}
    \item \emph{Common prefix}: We say that the protocol satisfies common prefix property with parameter $k$, if given the adopted chains $C_1$ and $C_2$ of any two honest nodes $n_1$ and $n_2$ at slots $l_1$ and $l_2$ respectively such that $l_1<l_2$, then by removing $k$ blocks from the end of $C_1$ we should get the prefix of $C_2$.

    \item \emph{Chain growth}: We say that the protocol satisfies chain growth with parameter $\zeta$, if given the adopted chains $C_1$ and $C_2$ of any an honest node $n$ at slots $l_1$ and $l_2$ respectively such that $l_1<l_2$, then $len(C_2)-len(C_1)\geq \zeta \cdot (l_2-l_1)$.

    \item \emph{Chain quality}:  We say that the protocol satisfies chain quality with parameter $\upsilon$ if given a consecutive run of $l$ blocks on a chain $C$ adopted by an honest node, has at least $\upsilon \cdot l$ blocks generated by honest nodes.
\end{itemize}

\subsubsection{Histogram matching}
\emph{Histogram matching} is a technique by which, the domain of a function is re-mapped such that its cumulative distribution function (\emph{cdf}), $F_i$, matches a target \emph{cdf}, $F_t$. To do this, for each value, $v_t$, in the domain of $F_t$, we find a value, $v_i$, in the domain of $F_i$, such that $F_i(v_i)=F_t(v_t)$. Using this we find the function, $F_{hm}(v_i)=v_t$, and apply it to all $v_i$. For details please refer to \cite{wikipedia_2019histmatch}.

Now in the next subsection, we describe the framework that the Ouroboros family of PoS protocols deploy.

\subsection{Framework of The Ouroboros Protocol}
\label{ssec:iop}

We briefly describe the functionalities used in the Ouroboros protocols. We use these functionalities along with our novel block power driven BPSM and CSR to achieve drastically better results. To focus on the novelty and avoid redundancy, we do not discuss the details, nuances, and implementations of these functionalities, which are well presented in the Ouroboros protocol papers.

The Ouroboros framework executes the protocol in a sequence of time periods called \emph{epochs} that are further divided into \emph{slots}, using the \emph{Network Time Protocol} (NTP) (Also used by Algorand). Each epoch contains a predefined number of slots. Each slot is of a predefined length, $t_{sl}$ ($t_{sl}>0$). The slot number, $l$, (counted from the start of the blockchain execution, with the slot corresponding to the genesis block being slot $l=0$), uniquely identifies a slot, as well as the epoch $ep$ that the slot $l$ is a part of. At the start of each epoch, $ep$, there is a \emph{pseudo-genesis block}, $B_{PG}^{ep}=\{seed^{ep},\{\{pk_0,r_0^{ep}\},\{pk_1,r_1^{ep}\}, \ldots \}\}$. It enlists the stake distribution, $\{\{pk_0,r_0^{ep}\},\{pk_1,r_1^{ep}\}, \ldots \}$, of all the stakeholders, as well as the seed randomness, $seed^{ep}$, that is used to determine the SBP in this epoch, $ep$. The stake distribution of the stakeholders is as per the last block of the second last epoch, i.e., $ep-2$. The seed randomness, is a result of a multiparty computation, \emph{private verifiable secret sharing} (PVSS) \cite{schoenmakers1999simple} (although in practice Cardano uses \emph{SCRAPE: SCalable Randomness Attested by Public Entities} \cite{cascudo2017scrape}). This seed randomness is based on the input of the SBP of the previous epoch, i.e., $ep-1$.

As shown in Fig. \ref{fig:es}, this framework of epochs, slots, and pseudo-genesis blocks helps in restricting the power of the adversary.
The adversary should not know the resulting random seed while it can influence it. If this is not the case, the adversary can always simulate the most favorable way to influence the random seed. Also, the adversary should not be able to change its stake distribution amongst its nodes after observing the random seed. If this is not the case, then the adversary can distribute its stake optimally based on the random seed to yield maximum effectiveness out of the BPSM.

\begin{figure}[!ht]
  \centering
  \begin{minipage}[b]{\columnwidth}
    \includegraphics[scale=0.27]{ES.png}
  \caption{\centering Epochs and Slots in Ouroboros} \label{fig:es}
  \end{minipage}
  \hfill
  \hspace{1pt}
  \hfill
  \begin{minipage}[b]{\columnwidth}
    \includegraphics[scale=.2]{NetworkN.png}
  \caption{The Network $N$} \label{fig:netN}
  \end{minipage}
\end{figure}

To stochastically select SBPs, Ouroboros uses non-ideal VRFs, such as digital signatures to obtain \emph{Verifiable Random Function} (VRF). The VRF, $\{\sigma_{uro}^{i,l,seed^{ep}},\sigma_{proof}^{i,l,seed^{ep}}\} \leftarrow VRF(sk_i^l,l,seed^{ep})$, takes as input, the secret key of the node $i$ corresponding to slot $l$, the current slot number $l$, and the seed randomness of epoch, $ep$; it produces, $\sigma_{uro}^{i,l,seed^{ep}}$, the uniform random output, of length $\kappa$ in bits, and $\sigma_{proof}^{i,l,seed^{ep}}$, the proof. Any entity can verify the legitimacy of $\sigma_{uro}^{i,l,seed^{ep}}$, using $VRF_{VERIFY}(\sigma_{uro}^{i,l,seed^{ep}},\sigma_{proof}^{i,l,seed^{ep}},pk_i,l,seed^{ep})$.
Please note, the result of a digital signature can be treated as a non-ideal VRF. However, to avoid manipulation of the probability of selection through BPSM, an \emph{ideal-VRF} is required. This is achieved using the 2-Hash-DH \cite{jarecki2014round} construction, as presented in Praos.

We use \emph{forward secure key signatures} \cite{bellare1999forward,itkis2001forward,david2018ouroboros}, as used in Praos. Forward secure key signatures, in essence, use a \emph{public key}, $pk_i$, and \emph{master secret key}, $msk_i$, pair for each node $i$. This $pk_i$ does not change. The $msk_i$ is used to generate a temporary secret key $sk_i^l$ (starting from $l=0$), which can verifiably be used only for slot $l$ by node $i$, after which $sk_i^{l+1}$ is generated and $sk_i^l$ is \emph{irrecoverably} destroyed. Forward secure key signatures prevent the adversary from corrupting an honest node to re-publish a block in its favor after the honest node has published a block in a particular slot. In this attack, the adversary will know exactly which nodes to corrupt, as they would have already published a block with a certain block power in a certain slot, thus making it public knowledge that they can achieve that block power in that slot.

Finally, in \emph{QuickSync}, as in v1 and Praos, \emph{moving checkpoints} are used to prevent long-range attacks such as \emph{stake-bleeding attacks} \cite{gavzi2018stake}. \emph{Moving checkpoints} are states of the blockchain, appropriately far enough into the history, such that no honest nodes would disagree with them. These moving checkpoints are assumed to be reliably and convincingly communicated to all the honest nodes joining the execution of the protocol (or any other node that has not witnessed the evolution of the honestly maintained public blockchain to establish the checkpoint for itself).

We summarize these concepts and notation in Table \ref{tab:cn}. Before explaining our approach that builds upon the Ouroboros framework, we first describe our network model, the adversary, and the assumptions.

\small
\begin{table*}
\caption{Notation} \label{tab:cn}
\begin{center}
\begin{tabular}{|p{1.5cm}|p{4cm}|p{1.7cm}|p{4cm}|}
\hline
Notation                   & Description                                              & Notation                        & Description                                                             \\ \hline
BPSM                       & Block Publisher Selection Mechanism                      & CSR                             & Chain Selection Rule                                                    \\ \hline
SBP                        & Selected Block Publisher                                 & PoW, PoS                        & Proof-of-Work, Proof-of-Stake                                           \\ \hline
v1, Praos                  & Ouroboros v1, Ouroboros Praos                            & FAC                             & Fully Adaptive Corruption                                              \\ \hline
$tps$                      & transactions per second                                  & $t_f$                           & time to finality                                                        \\ \hline
$pk_i$, $msk_i$            & public key, master secret key of node $i$                & $tpb$                           & transactions per block                                                  \\ \hline
$len(C)$                   & length of chain $C$ excluding genesis block              & $r_h$, $r_a$                    & relative stake of honest nodes, adversary                               \\ \hline
NTP                        & Network Time Protocol                                    & $t_{sl}$                        & length of a slot                                                        \\ \hline
$B_{PG}^{ep}$              & Pseudo-genesis block of epoch $ep$                       & $sk_i^l$                        & secret key of node $i$ for slot $l$                                     \\ \hline
$seed^{ep}$                & random seed used in epoch $ep$                           & $r_i^{ep}$                      & relative stake of node $i$ considered in epoch $ep$                     \\ \hline
VRF                        & Verifiable Random Function                               & $\sigma_{uro}, \sigma_{proof}$  & uniform random output of the VRF, its proof                             \\ \hline
$\kappa$                   & length of $\sigma_{uro}$                                 & $\eta$                          & probability of finality violation with fork starting from a given point \\ \hline
$\tau$                      & block propagation delay                                  & $P(B), P(C)$                    & power of block $B$, chain $C$                                           \\ \hline
$s$                        & scale factor                                             & $\alpha$                        & stake power; $\alpha=r\times s$;                                        \\ \hline
$B_C^l$                    & block $B$, part of chain $C$, published in slot $l$      & $C_{csr}$                       & chain selected by CSR; adopted/held by the node                         \\ \hline
$B_i^l$                    & block $B$, published in slot $l$ by node $i$             & $Bh_i^l,Bd_i^l$             & block header, data of block $B_i^l$                                     \\ \hline
$S_{{view}(i,l)}^{Chains}$ & set of chains known to node $i$ at the start of slot $l$ & $S_{{view}(i,l)}^{validChains}$ & chains of valid length in $S_{{view}(i,l)}^{Chains}$                    \\ \hline
MTR                        & Merkle Tree Root                                         & $r^{active}$                      & fraction of active relative stake                                       \\ \hline
$L$                        & lifetime of the protocol in slots                        & $k$                             & common prefix parameter                                                 \\ \hline
\end{tabular}
\end{center}
\end{table*}
\normalsize

\subsection{Our Model}

\subsubsection{Communication Network}
\begin{itemize}
    \item We consider a network, $N$, of honest nodes $\mathbb{H}$, having $r_h\geq1/2$ of the total relative stake.\footnote{For the ease of reference we refer to nodes that are a part of $N$, as nodes that are in $N$.}
    \item The maximum communication delay (block propagation delay) between any two nodes is at most $\tau$. In \emph{QuickSync}, $t_{sl}$ is set equal to $\tau$.
    This implies \emph{synchronous communication} amongst the nodes in $N$, w.r.t. time slots. Note that this is similar to the communication requirement in v1, Praos, and Algorand (Please refer to the comparative note in the Appendix for further details).
    \item All nodes not in $N$, are considered to be adversarial who represent $r_a$ relative stake.
    \item Thus, the adversary, $\mathbb{A}$, can be said to be comprised of nodes with malicious intent, $\mathbb{A}_a$, and nodes that follow the protocol but are not in $N$ due to their high communication delay, $\mathbb{A}_h$. The network is described in Fig. \ref{fig:netN}.
\end{itemize}

\subsubsection{The Adversary}
We use a dynamic (\emph{mobile} \cite{yung2015mobile}) byzantine adversarial model (which in terms of ability, due to its dynamic nature, is more powerful than the one considered in v1, and the same as the ones in Praos and Algorand). The dynamic nature of the adversary is what enables \emph{Fully Adaptive Corruptions} (FACs). FAC is the ability of the adversary to corrupt any node instantaneously. FACs threaten the security of the protocol when the adversary can know that corrupting a certain portion of the relative stake is better than corrupting another portion of the relative stake (of the same size). The adversary, however, is always bound by $r_h\geq1/2$.

In favor of the adversary, we assume that $\mathbb{A}_h$ is also a part of the adversary, as well as $\mathbb{A}_a$. Thus, we define the adversary, $\mathbb{A}$, as $\mathbb{A}=\mathbb{S} \setminus \mathbb{H}$.
In our model, any $a\in\mathbb{A}$ can:
\begin{itemize}
    \item read all communication between all nodes instantly.
    \item show any chain that it is aware of, to any honest node.
    \item corrupt any node (turn any honest node into an adversarial node) at any given moment provided $r_h\geq1/2$.
    \item freely, privately, and instantly communicate amongst all its nodes. All the nodes in $\mathbb{A}$ are assumed to be united by a single objective, in favor of the adversary. Hence, the adversary is considered to be a single entity.
\end{itemize}

\subsubsection{Assumptions}
\label{ssec:assumptions}
We make the following assumptions:
    \begin{itemize}
        \item The authors of Ouroboros do not explicitly state the block size or the number of transactions per block. So, for a fair comparison, we assume that a block of the Ouroboros protocol is similar to that of the Bitcoin protocol and that of \emph{QuickSync}\ in terms of size. That is to say, a block of the Ouroboros protocol, the Bitcoin protocol, and \emph{QuickSync}, having the same $tpb$ (typically we assume $tpb=2000$), take about the same time to propagate.
        \item Given the current state of the internet, it is safe to say that a typical block, similar to Bitcoin's, consisting of 2000 transactions, reaches 95\% percent of the nodes in 40 sec. \cite{bitcoin_network_monitor-dsn_research_group,blockchain.com_tpb} (\cite{decker2013information} does not discuss the average block size or the number of transactions per block). For ease of analysis, we ignore the 5\% tail and say that within 40 sec, all nodes hear of the block, i.e., that 40 sec is our upper bound on propagation, i.e., $\tau=40 $ sec.\footnote{We believe $\tau$ can be much less than $40$ sec as the advent of technology. The lower the $\tau$, better the security (w.r.t. a given $t_{sl}$).}
        \item The block \emph{building} time is assumed to be negligible compared to $\tau$.
        \item As is typical in the analysis of blockchain protocols, we assume that \emph{honest behavior} of the honest nodes is motivated and ensured by the reward schemes. Here, by honest behavior, we mean that under \emph{any} circumstance, the honest nodes follow the prescribed protocol without any deviation.
        \item In our analysis of $tps$, for the ease of comparison, we assume that the adversary and all active honest nodes publish blocks with their block data at every opportunity they get. In light of this assumption, we can claim that, $tps=\frac{tpb \times \zeta}{t_{sl}}$.
    \end{itemize}

With the above background, we explain the details of construction of our blockchain protocol, \emph{QuickSync}, in the next section.

\section{\emph{QuickSync}}
\label{sec:ourproto}

First, we introduce our protocol, \emph{QuickSync}. We then describe \emph{QuickSync}\ in detail, starting with the block publisher selection mechanism (BPSM), which in turn depends upon the chain selection rule (CSR) for \emph{QuickSync}\ (Section \ref{ssec:op_csr}). Then we explain how the block publisher builds and broadcasts the block (Section \ref{ssec:op_bp}). The last step in the protocol is block confirmation (Section \ref{ssec:op_bc}). In Section \ref{ssec:op_sr}, we briefly discuss the security of \emph{QuickSync}\ (Please refer to the Appendix for the complete security analysis \cite{Shoeb_qs_arxiv}).

\subsection{Introduction to \emph{QuickSync}}
\emph{QuickSync}\ builds on the Ouroboros framework to attain greatly improved performance while being resistant to a dynamic byzantine adversary with up to 50\% stake. To achieve this, \emph{QuickSync}, utilizes the novel concept of \emph{block power} ($P$). Block power is a numerical metric defined for every block, can be computed from the block header alone, and does not depend on the block data. The block power is calculated using the relative stake, $r$ and VRF output, $\sigma_{uro}$. The block power utilizes a special function introduced in this paper to be Sybil resistant.
To determine the chain that must be extended the nodes use the CSR. The CSR in \emph{QuickSync}\ is simply to pick the chain that has the maximum \emph{chain power}. The chain power of a chain is calculated by the summation of the block powers of all blocks of that chain.

At the start of each slot, every node publishes a block, extending the chain selected by the CSR. Since all nodes publish blocks and the block that is to be extended upon is determined by the CSR, the SBP for a slot can be said to be determined by the CSR in the next slot. Hence, the BPSM depends on the CSR. To ensure that the execution of the protocol w.r.t. slots is respected, only chains of a certain (for a given slot) length are considered valid. The valid length of a chain to be extended in the slot, $l$, is $l-1$, i.e., a chain $C$, must be of length, $len(C)=l-1$ to be considered by the CSR.

For the optimal performance of \emph{QuickSync}, we scale the relative stake, $r$, by a constant (parameter defined in the genesis block), $s$ ($s>0$), called the scale factor, to yield stake power $\alpha$, which is then used to determine the block power.

Please note: We overload the notation, $P(\cdot)$, to denote block power as well chain power; When a block (chain), $B_1$, has higher block (chain) power than another block (chain), $B_2$, we say that block (chain), $B_1$, is better than block (chain), $B_2$; We use the notation $B_C^l$, to refer to the block, $B$, that is a part of chain, $C$, that was published in slot $l$.

\subsection{Block Publisher Selection Mechanism and Chain Selection Rule}
\label{ssec:op_csr}
We propose the following CSR; to be followed by node, $i$, in slot, $l$, to pick a chain, $C_{csr}$, from a set of chains known to node $i$ at the start of slot $l$, $S_{{view}(i,l)}^{Chains}$, to be extended by publishing a block in slot $l$:
\begin{enumerate}
    \item From the set of chains, $S_{{view}(i,l)}^{Chains}$, select a subset of chains $S_{{view}(i,l)}^{validChains}$, such that $\forall C \in S_{{view}(i,l)}^{validChains}, len(C)=l-1$.
    \item Calculate the chain power $P(C)$, of every chain $C$ in $S_{{view}(i,l)}^{validChains}$. The chain with the maximum chain power is the $C_{csr}$.
    \item Publish a block extending chain $C_{csr}$.
\end{enumerate}

Since $2^\kappa$ is typically a very large number, the probability that two chains have the same chain power is clearly very low. In the event that this does happen, the next SBP will extend one of them, all nodes in $N$ will then accept this extension (This is very similar to the attack wherein the adversary provides two different block data with similar block headers, an attack strategy discussed in the Appendix).

\subsection{Calculating Block Power and Chain Power}
To calculate the chain power, $P(C)$, of a chain, $C$, sum the block powers, $P(B)$, of all the blocks $B \in C$.

To calculate the block power, $P(B_i^l)$, of a block $B_i^l$:
\begin{enumerate}
    \item Calculate the stake power, $\alpha_i^{ep}$, of node $i$ in epoch $ep$, by multiplying $r_i^{ep}$ by the scale factor, $s$.
    \item Normalize $\sigma_{uro}^{i,l,seed^{ep}}$ by dividing it by $2^\kappa$, obtaining $\sigma_{nuro}^{i,l,seed^{ep}}$ which has a range of $[0,1]$.
    \item Map the value $\sigma_{nuro}^{i,l,seed^{ep}}$, from the domain of a uniform \emph{pdf} with range $[0,1]$, to the corresponding domain of the function $f_{\alpha_i^{ep}}(x)=\alpha_i^{ep} x^{\alpha_i^{ep}-1}$, using histogram matching.
\end{enumerate}

\subsection{Block Publishing}
\label{ssec:op_bp}
Block publishing comprises of building a block and then broadcasting it. To publish a block in slot, $l$, a node, $i$, must build the block data, $Bd_i^l$, and the block header, $Bh_i^l$, as prescribed below. Once the block, $B_i^l = \{Bh_i^l,Bd_i^l\}$, is built, it is broadcast, completing the process of publishing block, $B_i^l$. In \emph{QuickSync}, to optimize the communication process, only the best block seen is propagated forward by the nodes instead of their own block.

\paragraph{Block building}
Block building is done at the start of the block, after the chain $C_{csr}$ has been selected by the CSR as the one to be extended. At the start of slot $l$, the node $i$, collects transactions, $\{tx_0, tx_1, \ldots \}$, received by the end of slot $l-1$, that have not yet been added to the blockchain and forms the block data, $Bd_i^l=\{tx_0, tx_1, \ldots \}$. The block header is then built to the format, $Bh_i^l=\{pk_i,r_i^{ep},l,\{hash(B_{C_{csr}}^{l-1}),null(B_{C_{csr}}^{l-1})\},$ $\{\sigma_{uro}^{sk_i^l,l,seed^{ep}},\sigma_{proof}^{sk_i^l,l,seed^{ep}}\},MTR(Bd_i^l)\}$; where $i$ is the node with public key, $pk_i$, and relative stake, $r_i^{ep}$; $l$ is the slot number; $ep$ is the epoch number; $\{\sigma_{uro}^{sk_i^l,l,seed^{ep}},\sigma_{proof}^{sk_i^l,l,seed^{ep}}\}$ is generated by $VRF(sk_i^l,l,seed^{ep})$; $MTR(Bd_i^l)$ is the \emph{Merkle tree root} of the block data $Bd_i^l$, it is what binds the block header to the block data $Bd_i^l$ (also, fixes order of $tx$ in $Bd_i^l$); $\{hash(B_{C_{csr}}^{l-1}),null(B_{C_{csr}}^{l-1})\}$ binds block $B_i^l$ as extending the chain ${C_{csr}}$ beyond block $B_{C_{csr}}^{l-1}$, and denotes whether the block $B_{C_{csr}}^{l-1}$, was a null block (Null blocks are part of an attack strategy discussed in the Appendix).

The block, $B_i^l$, is now ready to be broadcast.
Note, the block header is sent along with a digital signature over itself for sender authentication.

\paragraph{Broadcasting the best block}
Since all nodes will have valid blocks that are contenders for the best block and can be selected to be built on in the next slot, waiting to collect all blocks from all users in $N$ will require $\tau$ to be very high. So instead, the nodes only download the block data of the best block header seen yet. Thus, any node will only download and broadcast the block data of the best block header seen so far.
From the perspective of block propagation time, this method of communication is equivalent to communicating a single valid block.
Since the block header is sufficient to determine the block power of a given block, a node is aware of a block and its power as soon as it receives its block header. Once a node is aware of a block, it may or may not attempt to download its block data.
An honest node should always try to propagate the best block header it is aware of, to all other nodes, at any given moment.

Consider a network, as shown in Fig. \ref{fig:comm}. W.L.O.G., let us say that the node $n_0$ is the one that wants to build the next block and hence needs to know which is the best block in the current slot. The nodes $n_0, n_1, n_2, n_3, n_4, n_5$ have published blocks, $B_j=\{Bh_j,Bd_j\}; j=\{0..5\}$ with $P(B_1)<P(B_2)<P(B_3)<P(B_4)<P(B_5)$. Say, node $n_0$, sees the blocks in the following order: $B_1$, $B_4$, $B_3$, $B_5$, $B_2$. Now, first, $n_0$ sees $Bh_1$, and since it is better than $Bh_0$, and hence the best block it is aware of at the moment, begins to download $Bd_1$. Whether or not $n_0$ has finished downloading $Bd_1$, once it sees $Bh_4$, it will stop downloading $Bd_1$ and start downloading $Bd_4$. $n_0$, will, however, disregard $B_3$, as it already is aware of a better block, i.e., $B_4$. However, when $n_0$ hears of $Bh_5$, it will switch to downloading $Bd_5$ instead, as its block power is higher. Again, it will disregard $B_2$, as it is aware of a better block $B_5$.

While broadcasting blocks has been discussed here, the nodes, in fact, broadcast chains, in essentially the same manner as discussed above. This broadcasting of chains devolves to broadcasting blocks when the chains differ only by one block, i.e., the one published in slot $l$. We omit the discussion on broadcasting chains, i.e., the ones that differ from $C_{csr}$, by more than one block for simplicity and tractability. However, it is important to note that the nodes always propagate the best chain seen so far (similar to the best block propagation as discussed above).

\subsection{Block Confirmation}
\label{ssec:op_bc}
The nodes confirm all, but the most recent $k$ blocks, of the chain selected by the $C_{csr}$. This confirmation is consistent with \emph{k-finality} that is attained by \emph{QuickSync}.

\begin{figure}[!tbp]
  \centering
  \begin{minipage}[b]{\columnwidth}
  \includegraphics[scale=.55]{Communication.png}
\caption{Block download stack of a node} \label{fig:comm}
  \end{minipage}
  \hfill
  \hspace{1pt}
  \hfill
  \begin{minipage}[b]{\columnwidth}
  \includegraphics[scale=.25]{CP.png}
\caption{The forking attempt by the adversary to violate finality} \label{fig:CP}
  \end{minipage}
\end{figure}

\begin{figure}
\caption{\emph{QuickSync}\ Protocol}
\label{fig:proto}

\begin{minipage}{\columnwidth}
\begin{algorithm}[H]
\renewcommand{\thealgorithm}{}
\floatname{algorithm}{\emph{QuickSync}\ \emph{Protocol Pseudo-code};}

\caption{}
\label{protocol1}
\begin{flushleft}
Followed by node $i$ in slot $l$:

INPUT: \{$sk_i^l$, $r_i^{ep}$, $seed^{ep}$, $S_{{view}(i,l)}^{Chains}$, $s$, $\{tx_0, tx_1, \ldots \}$\}

Step 1: \emph{Chain selection}
\end{flushleft}
\begin{algorithmic}[1]
\STATE From $S_{{view}(i,l)}^{Chains}$, select the subset $S_{{view}(i,l)}^{validChains} : \forall C \in S_{{view}(i,l)}^{validChains} | len(C) = l - 1 $.
\STATE $\forall C \in S_{{view}(i,l)}^{validChains}$, calculate, $P(C)$.
\STATE Select the chain,

$C_{csr} : C_{csr} = \argmax_{C \in S_{{view}(i,l)}^{validChains}} P(C)$
\end{algorithmic}

\begin{flushleft}
Step 2: \emph{Block publishing}
\end{flushleft}
\begin{flushleft}
\qquad a) \emph{Block building}
\end{flushleft}
\begin{algorithmic}[1]
\STATE Build $Bd_i^l=\{tx_0, tx_1, \ldots \}$, and obtain $MTR(Bd_i^l)$.
\STATE $\{\sigma_{uro}^{i,l,seed^{ep}},\sigma_{proof}^{i,l,seed^{ep}}\} \leftarrow VRF(sk_i^l,l,seed^{ep}) $
\STATE Obtain $\{hash(B_{C_{csr}}^{l-1}),null(B_{C_{csr}}^{l-1})\}$
\STATE Build $Bh_i^l=\{pk_i,r_i^{ep},l,\{hash(B_{C_{csr}}^{l-1}),null(B_{C_{csr}}^{l-1})\}, \allowbreak \{\sigma_{uro}^{sk_i^l,l,seed^{ep}},\sigma_{proof}^{sk_i^l,l,seed^{ep}}\},MTR(Bd_i^l)\}$
\end{algorithmic}

\begin{flushleft}
\qquad b) \emph{Block broadcasting}
\end{flushleft}
\begin{algorithmic}[1]
\STATE Set $C_{broadcast}=\{C_{csr},B_i^l\}$
\WHILE{Current Slot $== l$}
\STATE Listen and receive $C_{rec}$ from other nodes
\IF {$P(C_{rec})>P(C_{broadcast})$}
\STATE Set $C_{broadcast}=C_{rec}$
\ENDIF
\STATE Broadcast $C_{broadcast}$
\ENDWHILE
\end{algorithmic}

\begin{flushleft}
Step 3: \emph{Block confirmation}
\end{flushleft}
\begin{algorithmic}[1]
\FOR{$j>0$; $j++$; $j\leq len(C_{csr}) - k$}
\STATE Confirm block, $B_C^j$.
\ENDFOR
\end{algorithmic}
\end{algorithm}
\end{minipage}
\hfill
\begin{minipage}{\columnwidth}
\begin{algorithm}[H]
\renewcommand{\thealgorithm}{}
\floatname{algorithm}{Chain Power}

\caption{$P(C)$}
\label{algoCP}

\begin{flushleft}
INPUT: Chain $C$

OUTPUT: $P(C)$
\end{flushleft}

\begin{algorithmic}[1]
\STATE $Sum=0$
\FOR{$l>0$; $l++$; $l\leq len(C)$}
\STATE $Sum += P(B_C^l)$
\ENDFOR
\STATE $P(C)=Sum$
\end{algorithmic}
\end{algorithm}

\begin{algorithm}[H]
\renewcommand{\thealgorithm}{}
\floatname{algorithm}{Block Power}

\caption{$P(B_C^l)$}
\label{algoBP}

\begin{flushleft}
INPUT: Block $B_C^l$

OUTPUT: $P(B_C^l)$
\end{flushleft}

\begin{algorithmic}[1]
\STATE From the header of block $B_C^l$, obtain $pk_i,r_i^{ep},\sigma_{uro}=\sigma_{uro}^{sk_i^l,l,seed^{ep}}$, where $i$ is the publisher of block $B_C^l$.
\STATE From the genesis block obtain $s$.
\STATE $\alpha_i^{ep} = r_i^{ep} \times s$
\STATE $\sigma_{nuro}= \frac{\sigma_{uro}}{2^{\kappa}}$
\STATE $P(B_C^l)= \sqrt[\alpha_i^{ep}]{\sigma_{nuro}}$
\end{algorithmic}
\end{algorithm}
\end{minipage}
\end{figure}

We conclude the presentation of \emph{QuickSync}\ with its pseudo-code, given in Fig. \ref{fig:proto}. The intuition behind \emph{QuickSync}\ is discussed in Section \ref{ssec:op_oa}. The power of our approach can be summarized as follows: The nodes collectively, as common knowledge, know which chain to adopt, which then becomes the honest chain. As soon as a fork is witnessed, adversarial or not, the nodes know whether or not to adopt it; the nodes are not confused, as they would be in protocols that do not differentiate between published blocks, such as \emph{Bitcoin}\ or Ouroboros.
However, the adversary can still attempt to fork and develop chains and use them to violate finality. We prove that \emph{QuickSync}\ is secure against such attempts. In the next section, we discuss security briefly.

\subsection{\emph{QuickSync}\ Security and Performance}
\label{ssec:op_sr}
\subsubsection{\emph{QuickSync}\ Security Analsysis}
To prove the security of \emph{QuickSync}, w.r.t. \emph{liveness} and \emph{persistence}, we need to establish the three prerequisite properties of a blockchain protocol, i.e., common prefix, chain growth, and chain quality, as given in Section \ref{ssec:reqbp}. These properties are established by Theorem \ref{theo:sr}:

\begin{restatable}[]{theorem}{theosr}
\label{theo:sr}
    The probability that any of; common prefix with parameter $k$, chain growth with parameter $\zeta=1$, chain quality with parameter $\upsilon=1/k$ are violated in the lifetime of the protocol, thereby violating liveness and persistence is:
        $$\varepsilon_{lp} \leq 2\varepsilon_{cp}$$
\end{restatable}

Further:

\begin{restatable}[]{proposition}{propfac}
\label{prop:fac}
    \emph{QuickSync}\ is resilient to \emph{Fully Adaptive Corruptions} (FACs).
\end{restatable}

We provide detailed analysis and the proofs in the Appendix.

\emph{QuickSync}\ does not require a \emph{Forkable Strings} analysis, as presented in v1 and Praos. Due to the elegance and naturality of our approach, \emph{QuickSync}\ avoids the inherent complexities of the Ouroboros protocols.
All observed (public) forks are immediately and trivially resolved using chain power as the nodes will only build on the chain with the highest chain power. If an adversarial chain with higher chain power than an honest chain is revealed before it can violate finality, that adversarial chain becomes the new honest chain. To violate finality (and hence common prefix), an adversarial chain must have higher chain power than the honest chain while forked for at least $k$ blocks; we prove that the probability of this is exponentially bounded with $k$.

\subsubsection{\emph{QuickSync}\ Performance Analysis}
How we optimized to claim the following performance for \emph{QuickSync}\ is provided in the Appendix. The summary of our analysis is, \emph{QuickSync}\ improves $t_f$ by factor of 3 and marginally improves  $tps$  over  Ouroboros v1. Tables \ref{tab:com_f} and \ref{tab:com_tps} present a comparison of $t_f$ and $tps$ respectively, between \emph{Bitcoin}, Ouroboros v1, and \emph{QuickSync}.

\section{The Intuition behind \emph{QuickSync}}
\label{ssec:op_oa}
We require that our protocol, \emph{QuickSync}, satisfies the following two requirements:
\begin{itemize}
    \item To ensure security against FACs, the SBP must not be revealed before it publishes the block.
    \item Forks costs performance. Hence, forking amongst the honest nodes must be avoided. Thus, at any time, ideally, we must have only one block that should be extended.
\end{itemize}

\begin{table*}[!t]
\caption{Comparison of Time to Finality (in minutes)}
\subcaption*{BTC: Bitcoin, v1: Ouroboros v1, QS: \emph{QuickSync}}
\label{tab:com_f}
\begin{center}
 \begin{tabular}{||*{13}{c|}|}
 \hline\hline
 \diagbox[width=1.5cm, height=.7cm]{$r_a$}{$1-\eta$} & \multicolumn{3}{c|}{0.95} & \multicolumn{3}{c|}{0.99} & \multicolumn{3}{c|}{0.995} & \multicolumn{3}{c||}{0.999} \\ [0.5ex]
 & BTC & v1 & QS & BTC & v1 & QS & BTC & v1 & QS & BTC & v1 & QS \\
 \hline\hline
 0.10 &30 &4 &2   &40 &6 &2   &40 &8 &3   &50 &10 &4    \\
 0.15 &30 &5 &2   &40 &10 &4   &60 &11 &4   &80 &16 &6    \\
 0.20 &50 &8 &3   &70 &14 &5   &80 &17 &6   &110 &24 &8    \\
 0.25 &60 &13 &4   &100 &23 &8   &120 &27 &10   &150 &37 &13    \\
 0.30 &100 &22 &8   &160 &38 &13   &180 &46 &15   &240 &63 &21    \\
 0.35 &170 &42 &14   &270 &74 &24   &310 &88 &28   &410 &121 &38    \\
 0.40 &360 &105 &31   &580 &183 &55   &670 &217 &66   &890 &296 &90    \\
 0.45 &1370 &486 &127   &2200 &831 &226   &2560 &980 &268   &3400 &1327 &361    \\
 0.46 &2110 &794 &203   &3400 &1347 &355   &3960 &1586 &428   &5260 &2143 &584    \\
 0.47 &3710 &1487 &362   &5970 &2506 &632   &6950 &2946 &747   &8330 &3969 &1041    \\
 0.48 &8030 &3588 &826   &- &5991 &1434   &- &7028 &1680   &- &9438 &2335    \\
 \hline\hline
\end{tabular}
\end{center}
\end{table*}

\begin{table*}[!th]
\caption{Comparison of $tps$} \label{tab:com_tps}
\begin{center}
 \begin{tabular}{|c|c|}
 \hline\hline
 & $tps$\\ [0.5ex]
 \hline\hline
 Bitcoin & $\frac{tpb}{avg. time per block (sec)}=\frac{2000}{600}=3.3$   \\
 \hline
Ouroboros v1 & $\frac{tpb \times r^{active}}{t_{sl}} \implies tps<50$ $\forall$ $r^{active}<1$     \\
 \hline
 \emph{QuickSync} & $\frac{tpb}{t_{sl}} = 50$ $\forall$ $r^{active}>0$\\
 \hline\hline
\end{tabular}
\end{center}
\end{table*}

To fulfill the first requirement, the computation required by the BPSM must be done privately. For the second requirement, the BPSM must select exactly one block publisher as the SBP. Satisfying both of these requirements together is non-trivial, as we must privately, securely, provably, and efficiently select exactly one party in a multiparty weighted coin-toss with guaranteed output using a seed-randomness (which is easy to generate using PVSS or SCRAPE as mentioned earlier). The BPSM presented in this paper solves for both these requirements through the CSR. In contrast, v1 solves only the second requirement but not the first, while Praos solves only the first requirement but not the second.

Each node publishes its block in an attempt to have it selected as the next block to be added to the blockchain. However, if the nodes arbitrarily choose one of the blocks they received, they might select different blocks, hence causing forks. Suppose, if, from a given set of options, \emph{all the nodes know which block to extend}. If this is the case, then all the nodes would extend the same block and hence avoid forks. Now since all the nodes will publish their own blocks, and only one must be selected amongst them, in such a way that all arrive at the same result, we establish a metric called \emph{block power}, by which all the nodes must evaluate the competing blocks. The block (chain) with the maximum block (chain) power is selected. This metric must, of course, be dependent on the stake of the block publisher so that our protocol can be PoS-based.

Naive implementations of the above approach are vulnerable to Sybil attacks. To solve for this, we present a Sybil attack resistant function:
\begin{equation}\label{eqn:sa_res}
    f_{\alpha} (x) = {\alpha} x^{{\alpha}-1}
\end{equation}

where $x$ represents the block power, $\alpha$ is the stake power of the block publisher, and the resulting $f_{\alpha} (x)$ is the probability distribution function (\emph{pdf}) of the block power of the block.

To be Sybil resistant, we must ensure that whether a node is represented as a single entity of stake $\alpha$ or two entities of stake power $\alpha_1$ and $\alpha_2$, the \emph{pdf} of the node's effective block power (the node's maximum block power, as one or more entities) remains the same. Hence, the node has the same probability of becoming the SBP, regardless of division into smaller nodes or aggregation into bigger ones.

The function in Eqn. \ref{eqn:sa_res} is resilient to Sybil attacks due to the following property:\\
\begin{center}
    \boxed{$$f_{\alpha}(x)= f_{\alpha_1}(x)\int_0^x f_{\alpha_2}(y) dy + f_{\alpha_2}(x)\int_0^x f_{\alpha_1}(y) dy$$}
\end{center}

where $\alpha=\alpha_1+\alpha_2 \; \forall \; \alpha_1,\alpha_2>0$, the attacker splitting its computing power into two entities.

To utilize $f_\alpha(x)$, we map the uniformly distributed normalized output over $[0,1]$, $\sigma_{nuro}$, of the private computation required by the BPSM to the domain of $f_\alpha(x)$, using histogram matching, where $\alpha$ is the stake power of the block publisher. The re-mapped domain is then used as the \emph{block power}.

To show why and how our block power approach is powerful, we use an example. Consider a fork, where nodes, $n_a$ and $n_b$, both are aware of two blocks, $B_1$ and $B_2$ viable for extension. Now, in both Ouroboros and \emph{Bitcoin}, there is no distinction made between the two blocks. Hence, the node, $n_a$, may extend block $B_1$, while node, $n_b$, extends block $B_2$. This causes an extension of the fork. This is what \emph{QuickSync}\ gracefully avoids. The same scenario in \emph{QuickSync}\ would lead to both nodes extending either block $B_1$ or block $B_2$, depending on their block powers. This collective decision to select one block that is to be extended resolves the fork. Since the forks are immediately resolved, it is equivalent to the forks never occurring. This results in avoiding forking amongst honest nodes and is why the block power approach is so powerful.

\section{Discussion on \emph{QuickSync}\ Parameters}
\label{sec:disc}

In this section, we discuss how to set the three parameters relevant to the protocol \emph{QuickSync}. Two parameters are endogenous to the protocol, namely, $s$ and $t_{sl}$. $s$ is the factor by which the relative stake of a node is scaled to assign it the stake power. In \emph{QuickSync}, $s$ affects the $t_f$  significantly and hence should be chosen to be optimal. We recommend using $s=8$, although any $s>4$ should suffice. $t_{sl}$ is the time slot length in units of time. $t_{sl}$ greatly impacts transaction per second ($tps$), time to finality ($t_f$), and relative stake of the honest nodes ($r_h$). Ideally, $t_{sl}$ must be set equal to $\tau$ or at least $\tau$. $\tau$ is the upper bound on the block propagation delay. It depends upon the network and must be estimated. Decreasing $t_{sl}$, increases $tps$ and reduces $t_f$ which is very favourable. However, this comes at the risk of reducing it below the actual value of $\tau$, causing $r_h$ to drop below half, compromising the security of the protocol. Given the current state of the internet we suggest $t_{sl}=\tau=40$ sec (from \cite{bitcoin_network_monitor-dsn_research_group,decker2013information}). Once we set $t_{sl}$, it need not be changed as internet connectivity will only get better.

Another crucial parameter is $k$, which is exogenous to the protocol. It is an important factor from the perspective of the consumer of the blockchain. $k$ is the number of blocks that a node should wait to confirm a block for a given confidence level $1-\eta$ against an adversary with relative stake $r_a$. As the block gets deeper into the blockchain, the confidence of the block's placement in the ledger increases.

\section{Conclusion}
\label{sec:conc}
PoS-based protocols are attracting attention in the literature but may potentially be vulnerable to FACs, as in v1. In this paper, we proposed a novel PoS-based blockchain protocol, namely, \emph{QuickSync}. To design it, we introduced a block power metric based on a \emph{Sybil attack resistant function} (Eqn \ref{eqn:sa_res}). We showed that \emph{QuickSync}\ satisfies chain prefix, chain growth, and chain quality properties with appropriate parameters (Theorem \ref{theo:sr}). We also showed that \emph{QuickSync}\ is resistant to FACs (Proposition \ref{prop:fac}).
Our analysis showed that \emph{QuickSync}\ performs better than the Ouroboros protocols for $t_f$ (time to finality; by a factor of 3) and $tps$ (transaction per second).
We leave it for future work to explore the application of our BPSM and CSR to build blockchain protocols outside the Ouroboros framework.

We believe the concept of \emph{block power} and {chain power} metrics are very useful in designing PoS-based blockchain protocols. The possible applications of Sybil attack resistant functions in other scenarios involving Sybil attacks need to be further explored.

\newpage

\bibliographystyle{splncs04}

\section{Introduction}
\label{sec:intro}

A \emph{blockchain} is an append-only, secure, transparent, distributed ledger. It stores the data in \emph{blocks} connected through immutable cryptographic links, with each block extending exactly one previous block.
Introduced in Bitcoin \cite{nakamoto2008bitcoin}, blockchain is one of the most significant technological innovations of this century. Blockchains have been rigorously studied and applied to a myriad of use cases that involve establishing distributed trust. The underlying technical problem that Bitcoin solves through blockchain is \emph{byzantine fault tolerant} \emph{distributed consensus} in a decentralized system.

We expect a blockchain to consist of a singular \emph{chain} of blocks. However, delays in communication and adversarial attacks may cause \emph{forks}, creating ambiguity as to extend which block. To avoid forks, we require that only one \emph{node} publish a block at a time. Thus, we need a \emph{distributed mechanism}, which we refer to as \emph{block publisher selection mechanism} (BPSM) to select a node as \emph{selected block publisher} (SBP). To resolve forks, in case they occur, we require the protocol to specify a \emph{chain selection rule} (CSR). The BPSM and CSR, functionally characterize a blockchain protocol. Nodes are incentivized by reward schemes to participate and follow the protocol.

Bitcoin blockchain protocol uses a \emph{Proof-of-Work} (PoW) based BPSM, and \emph{longest chain} as the CSR. In the PoW mechanism, each node has a different cryptographic puzzle to solve, of the same level of difficulty. Once a node solves the puzzle, it publishes the block, i.e., proposes the block to be added to the chain. The rest of the nodes verify and add the first valid block they receive to their blockchain.

Bitcoin, though a great innovation, has certain challenges when it comes to efficiency and performance. Bitcoin consumes a high amount of electrical power to function. As of writing this paper, the Bitcoin network uses an estimated $112\times10^{3}$ Peta hashes per second and annual power consumption of $75$ TWh \cite{digiconomist}. A blockchain's performance can be measured by two metrics: i) \emph{transactions per second} ($tps$), and ii) \emph{time for finality} ($t_f$), i.e., the time required to confirm a transaction. Typically in Bitcoin $tps=4$ and $t_f=60$ minutes \cite{blockchain.com}. Due to the poor $tps$, it is unable to scale to high volumes, and the high $t_f$ deters usability and adoption.
Attempts such as \emph{GHOST} \cite{sompolinsky2013accelerating} aim to improve the performance, by using a different CSR. The BPSM being still PoW-based, its power consumption remains high. Towards addressing high power consumption, researchers proposed \emph{Proof-of-Stake} (PoS) based BPSM.

PoS based blockchain protocols, such as Algorand \cite{gilad2017algorand} and Casper \cite{buterin2017casper}, stochastically select an SBP with probability proportional to its \emph{relative stake}. This approach is also consistent with the expectation that nodes that are stakeholders would not want to endanger the system. The \emph{Ouroboros} protocols \cite{kiayias2017ouroboros,david2018ouroboros,badertscher2018ouroboros,kerber2018ouroboros} are popular PoS-based protocols, amongst others. Ouroboros is not only academically published\footnote{Some of PoS protocols are not academically published, e.g., Casper} in a peer-reviewed forum, but also is the foundation for the crypto-currency \emph{Cardano} \cite{cardano}.

\emph{Ouroboros v1} (v1) \cite{kiayias2017ouroboros} achieves high $tps$ and better $t_f$ than Bitcoin. However, for a blockchain protocol to be completely secure, it must be immune to \emph{fully adaptive corruption}s (FACs), i.e., a \emph{dynamic adversary}. Ouroboros v1 is not immune to FACs.
\emph{Ouroboros Praos} (Praos) \cite{david2018ouroboros} uses a different BPSM. Praos does solve the security weakness, but does not improve performance. While both \emph{Ouroboros Genesis} \cite{badertscher2018ouroboros} and \emph{Ouroboros Crypsinous} \cite{kerber2018ouroboros} protocols enhance the Ouroboros protocol, they too do not improve performance.

In this work, we propose a novel blockchain protocol, \emph{QuickSync}\ that is secure against FACs, and achieves slightly better $tps$, and improves on the $t_f$ by a factor of 3, as compared to Ouroboros v1. Essentially, it quickly synchronizes (resolves) the forks that arise. To build \emph{QuickSync}, we employ the framework of the Ouroboros protocol. \emph{QuickSync}\ differs from v1 and Praos, in both, the BPSM and the CSR.
The key idea is, we propose a metric called \emph{block power}, assigned to each block. With this, we compute \emph{chain power} of an every competing chain. The chain power of a chain is the sum of block powers of all the blocks of the chain. Using chain powers, we establish the \emph{best chain}, the one with the highest value for this metric, that the node must build on from a given set of chains. It results in ensuring that all forks are trivially resolved, except for the ones generated by the adversary. Block power is a function of the output of the node's privately computed \emph{Verifiable Random Function} (VRF) output based on the digital signature of the node, seed randomness, and the slot counter. The VRF output is not revealed until the block is published, thus enabling immunity against fully adaptive corruptions. Block power is also a function of the relative stake that the node holds, to enable the PoS aspect of the mechanism. A naive implementation of such a concept is vulnerable to Sybil attacks. To solve this, we present a \emph{Sybil attack resistant function}, which we utilize for the block power metric, with the help of a technique called \emph{histogram matching}.

As multiple nodes publish blocks at the same time, it may seem that there will be several forks in \emph{QuickSync}, as is the case in the other PoS protocols such as Praos. The key novelty here is that we resolve these forks immediately using block power rather than relying on the network to eventually resolve them using the longest chain CSR. Thus, \emph{QuickSync}\ is in sharp contrast to other PoS-based mechanisms that \emph{do not differentiate} between the published blocks.

Researchers showed that any blockchain protocol satisfying the three properties: \emph{common-prefix}, \emph{chain-growth}, and \emph{chain-quality} implements a robust transaction ledger  \cite{garay2015bitcoin,kiayias2015speed,pass2017analysis}. First, we prove that \emph{QuickSync}\ satisfies these three properties (Theorem \ref{theo:sr}). Next, we ascertain that our protocol is immune to FACs (Proposition \ref{prop:fac}). We also examine our protocol for different attack strategies and show resistance to them. In summary, the PoS-based blockchain protocol, \emph{QuickSync}\ fixes the security weakness of Ouroboros v1 while improving on performance and performs better in terms of $tps$ and $t_f$ by about an order of magnitude as compared to Bitcoin.

The rest of the paper is organized as follows. In Section \ref{sec:rel}, we summarize the related work in this domain. In Section \ref{sec:prelim}, we explain the relevant preliminaries. In Section \ref{sec:ourproto}, we describe our protocol, \emph{QuickSync}, and then analyze its security in the following section. Following a comparative note in Section \ref{ssec:cnv1pa}, we conclude the paper in Section \ref{sec:conc}. In Appendix, we discuss the intuition behind \emph{QuickSync}, analyze the effectiveness of attack strategies against \emph{QuickSync}, and finally, discuss how to set the parameters for \emph{QuickSync}.

redpajama_set_name: RedPajamaArXiv


text:
Geodis Wilson Scoops Innovation Award
London, UK, November 22, 2012 — CargoWise®, a global leader in technology solutions for logistics service providers (LSPs), congratulates global freight management company Geodis Wilson on winning the New Process Innovation Award at the 2012 Global Freight Awards announced last night in the Planit Embankment Gardens in London.
One of seven finalists in the New Process Innovation category, Geodis Wilson was recognized for a €20million project which will see separate software applications replaced with a single, centralized corporate database based on the ediEnterprise platform from CargoWise. The project was recognized because of the ambitiousness of its approach and the resulting productivity improvements which are expected to reach 25 percent across the company's global operations.
In accepting the award, Geodis Wilson CIO Håkan Nilsson expressed his delight at the fact that the project had achieved a level of recognition which he hoped would inspire others to take a more innovative and comprehensive approach to the challenges faced by the freight forwarding and logistics industry.
"Of course we're delighted to receive this award, and also delighted that the industry is recognizing the importance of process innovation as a key driver of the industry," Nilsson said. "I hope awards like this will help to drive the market forward into an era of greater productivity driven by innovation."
In responding to the award, CargoWise CEO Richard White emphasized the crucial role innovation plays in ensuring that the logistics and freight forwarding industry continues to develop tools and procedures to ensure the success of its customer base, and ultimately of the entire global economy.
"Logistics is at times a business that seeks to minimize IT costs and innovation can often suffer because of this," White says. "Geodis Wilson is a shining example of how a significant focus on IT leadership and innovation and a strong IT investment program can improve processes, lower overall costs and drive business success."
Simon Clark, Vice President of Business Development – Europe for CargoWise, also congratulated Yusen Logistics, which secured a place as finalist in the Environment Award, and SBS Worldwide which was recognized as a finalist in the prestigious Freight Forwarder of the Year category.
"The only way to succeed is to be pushing constantly at the boundaries of what you think is possible," says Clark. "Whenever people in such a deep-rooted and established industry are brave and creative enough to take an innovative approach to a challenge, we think it's important that they be recognized.

redpajama_set_name: RedPajamaCommonCrawl


text:
Q: IPtables used for load balancing I am trying to use iptable for load balancing.
The rule I have set is as follows wherein I want to route requests coming to my server with ipaddress 10.x.x.4 to internal ips of the server 10.x.x.1:1010 , 10.x.x.2:1010 and 10.x.x.3:1010
iptables -t nat -A PREROUTING -p udp -d 10.x.x.4 --dport 1010 -m state --state NEW -m statistic --mode nth --every 3 --packet 0 -j DNAT --to-destination 10.x.x.1:1010

iptables -t nat -A PREROUTING -p udp -d 10.x.x.4 --dport 1010 -m state --state NEW -m statistic --mode nth --every 3 --packet 0 -j DNAT --to-destination 10.x.x.2:1010

iptables -t nat -A PREROUTING -p udp -d 10.x.x.4 --dport 1010 -m state --state NEW -m statistic --mode nth --every 3 --packet 0 -j DNAT --to-destination 10.x.x.3:1010

When I execute , the first 4 packets gets routed to each ipaddress correctly.
The 5th packet doesn't get routed and is getting dropped.
How do I debug this issue. Should I increment to value given to --packet ? What should be the correct rule?

A: You should increment --packet from 0 to n-1 in each command line. Where n is the number given as the parameter to --every.

redpajama_set_name: RedPajamaStackExchange


text:
The Daily Caller: Warren Says She's 'Open' To Suspending Deportations Of Illegal Aliens - America Rising PAC
The Daily Caller: Warren Says She's 'Open' To Suspending Deportations Of Illegal Aliens
"Elizabeth Warren is single-handedly exposing her party's open-borders agenda, which would endanger communities across the country."
Warren's call for a deportation suspension came after she released her $52 trillion Medicare for All plan. The senator said a large source of funding for the proposal would come from the legalization of illegal aliens living in the country, but as the Daily Caller News Foundation first noted, her data wrongly cited a Congressional Budget Office report that did not take into account universal coverage.
Conservative operatives promptly attacked the Massachusetts senator for wanting a ban on deportations.
"Elizabeth Warren is single-handedly exposing her party's open-borders agenda, which would endanger communities across the country. It's no wonder national Democrats are panicking over the electability of their 2020 frontrunners," America Rising Communications Director Chris Martin told the DCNF on Friday.
This is an excerpt from The Daily Caller. For the full article click here.


Home » Blog » 4th of July Real Food Recipe Roundup!
Before we dive in though, I want to share that starting next week I'm going to be introducing you to some guest posters on my blog, most of whom have not made an appearance here before. So I'm excited to introduce you to some new people and sites I think you'll like. Guest posts (along with posts I've prepared in advance) are always a fun way to give me a little downtime when I need it. We're currently visiting my family up north, but when we get back, we'll be packing to move out of our house (into temporary housing until our new house is ready). While true "downtime" is highly unlikely anytime in the near future, I will need some focused time away from the blog to orchestrate all of this madness!
So anyway, I hope you're able to enjoy some downtime with your family and friends over the upcoming holiday weekend and that these recipes help make things easier. Enjoy!
I'd love to hear your holiday favorites in the comments!
Okay… I am an ice cream fanatic… I want a real food, non-dairy, non-coconut recipe for ice cream… Does it is exist?
If you can get your hands on an electric (or hand crank) ice-cream machine you could make your own. Great idea for a 4th party! I know all the kiddos around there parts love when I get out the ice-cream maker.
We use raw milk from our Jersey cow, pastured eggs, and only real ingredients. It's the best ice-cream you'll ever eat!
So many great ideas, thanks for sharing. I love the patriotic kebob idea; I'll definitely be adding that one to our festivities this weekend! I'm posting a Red White & Blue Popsicle tomorrow that will go perfectly with the kebabs. Fun treats without the added sugar!
I made the baked beans and the fruit kabobs with dip yesterday and they were huge hits!! I love how easy the recipes are on here!


text:
President appoints Justice Ranjan Gogoi as next Chief Justice of India
President of India Ram Nath Kovind has appointed Justice Ranjan Gogoi as next Chief Justice of India as per Article 124 of the Constitution. He will assume office of Chief Justice on 3rd October, 2018 after retirement of incumbent Chief Justice, Justice Dipak Misra.
At present Justice Gogoi is senior-most judge of Supreme Court. His appointment was as per convention, where outgoing CJI recommends name of senior-most judge for appointment by President as his successor. He will be become 46th Chief Justice of India and shall He will have tenure of about 13 months from October 3, 2018 till his retirement on November 17, 2019.
Justice Ranjan Gogoi
Justice Gogoi was born on November 18, 1954. He is native of Assam and is son of former Assam Chief Minister Keshab Chandra Gogoi. He had joined Bar in 1978 and practiced mainly in Gauhati High Court mainly on constitutional, taxation and company matters.
He was appointed as permanent judge of High Court in February 2001. He was transferred to Punjab and Haryana High Court in September 2010 and was appointed its Chief Justice in February 2011. He was elevated to the Supreme Court in April 2012.
In Supreme Court, Justice Gogoi had led important benches that have dealt largely with issue of corruption in politics and public life. He has led apex court bench which ordered Centre to set up special courts to exclusively try MPs and MLAs as means to de-criminalise politics. His Bench is also monitoring progress made by government in appointment of anti-corruption ombudsman Lokpal.
Justice Gogoi was one of the four most senior Supreme Court judges (along with Justices J Chelameswar, M B Lokur and Kurian Joseph) who held January 12, 2018 press conference bringing up issue of selective assignment of sensitive cases by recent CJIs to certain judges in the Supreme Court.
Month: Current Affairs - September, 2018
Category: Awards, Persons & Places in News • Persons in News
Topics: appointments • Article 124 • Chief Justice of India • National • Persons in News • President • Ram Nath Kovind • Ranjan Gogoi • Supreme court


text:
<?php

$charset = 'iso-8859-1';

// Page info
$page_name = $this->GetPageTag();
$page_addr = $this->href();

header("Content-Type: text/html; charset=$charset");

//  : metas & style
if ($this->GetMethod() != 'show'
	|| !empty($_REQUEST['phrase'])
	|| !empty($_REQUEST['show_comments'])
	|| isset($_REQUEST['time']))
{
	$additionnal_metas = "<meta name=\"robots\" content=\"noindex, nofollow\" />\n";
}
else
{
	$additionnal_metas = '';
}
$meta_keywords = $this->GetConfigValue("meta_keywords");
$meta_description = $this->GetConfigValue("meta_description");
$imported_style = isset($_COOKIE["sitestyle"]) ? htmlspecialchars($_COOKIE["sitestyle"], ENT_COMPAT, YW_CHARSET) : 'wakka';

// Page contents
$body_attr = ($message = $this->GetMessage()) ? "onLoad=\"alert('".addslashes($message)."');\" " : "";
$wiki_name = $this->GetWakkaName();
$page_search = $this->href('', 'RechercheTexte', 'phrase=' . urlencode($page_name));
$root_page = $this->ComposeLinkToPage($this->config["root_page"]);
$navigation_links = $this->config["navigation_links"] ? $this->Format($this->config["navigation_links"]) : "";
$user_name = $this->Format($this->GetUserName());
$disconnect_link = $this->GetUser() ? '(href('', 'ParametresUtilisateur', 'action=logout') . "\">Déconnexion)\n" : '';

?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

		<meta http-equiv="Content-Type" content="text/html; charset=<?php echo $charset ?>" />
		<meta name="keywords" content="<?php echo $meta_keywords ?>" />
		<meta name="description" content="<?php echo $meta_description ?>" />
		<?php echo $additionnal_metas ?>
		<title><?php echo "$wiki_name:$page_name" ?></title>
		<link rel="stylesheet" type="text/css" media="screen" href="wakka.basic.css" />

	<body <?php echo $body_attr ?> >

		<a href="<?php echo $page_addr ?>/resetstyle" accesskey="7">

<?php echo $wiki_name ?>

		<a href="<?php echo $page_search ?>"><?php echo $page_name ?>

		<?php echo $root_page ?> ::
		<?php echo $navigation_links ?> ::
		Vous êtes <?php echo $user_name ?> <?php echo $disconnect_link ?>

redpajama_set_name: RedPajamaGithub


Home » Forum » Contractors Talk Forums » General Discussion » 650 Sq. Ft. ADU, Stick It Or SIP It?
650 Sq. Ft. ADU, Stick It Or SIP It?
I am doing the Architectural plans for a 650 sq. ft. Accessory Dwelling Unit (ADU) and the main designer on this project wants to use SIPs for walls and roof systems. Since the ADU is so small, I think that it would be better ie. less expensive overall for the same energy efficiency to stick frame it with a truss system.
It will be slab-on-grade and it is a simple rectangle with 9' ceilings. Pretty basic stuff that I can prescriptively engineer. The SIPs construction would require a licensed engineer as the house is in a seismic design category of S. I do not have any experience with SIPs so perhaps I am wrong about stick framing being the better option. I know that each system has its pros and cons but I am looking for validation from you guys for my opinion so that I can charge prescriptive engineering fees....mmmuuuuaaaahahahah!
But seriously, I think that framing it would be less hassle and better overall.
Am I wrong in your never to be humble opinions?
Re: 650 Sq. Ft. ADU, Stick It Or SIP It?
I'm assuming you're talking cost. What R values for walls and ceiling, what general location?
Normally I'd say stick. Long term repairs are also easier to deal with.
Mostly I am asking about cost, yes.
R values will be around R-19 in walls and since this is southern California, the ceiling and the wall values can vary depending on the type of construction, types of windows (SHGC and U-factors), Heating/Cooling unit type, etc.
Ceilings will probably be around R-19 to R-38 depending all the above.
I am sure there are/will be difficuties with running electrical and plumbing etc. in SIP walls that I am not aware of.


Upgrade your workout gear and carry your stuff using gym tote bags. Custom gym tote bags are so in right now that you simply have to order from Unionwear. We can customize gym totes to ensure that you get the style, color, and size that you want.
More people are getting health conscious and gym memberships are soaring high. Custom gym tote bags ensure that you can get to the gym in style, especially when you have personalized ones that are embroidered with your initials.
Planning to give out USA-made custom embroidered gym tote bags? We are a fair labor manufacturer and we guarantee high-quality and durable bags for our clients.


text:
Discovery Channel » Programs » Chop Shop 2
Chop Shop 2
'Return to the Garage for the Second series of 'Chop Shop'. This series joins, Bernie and Leepu a they create cars for the stars as they undertake celebrity commissions for some well-known faces in entertainment and sport, including French footballer David Ginola, former England rugby captain, Lawrence Dallaglio, and musician and television personality, Jools Holland. Their first supercar for a superstar is for Spandau Ballet pop legend and British hard man actor, Martin Kemp. They take a scrapped Saab and turn it into a turbo-charged gangster racing machine. But when they take it out for its first test drive, Martin finds that it is not just unfinished but unsafe. With only three weeks before it has to be driven at the British GT event at Rockingham race track, will the boys be able to finish it in time and salvage the reputation of the 'Chop Shop'?


text:
Crown Princess Victoria updated on how Sweden is perceived abroad
Crown Princess Victoria of Sweden and her husband Prince Daniel have held a digital meeting with representatives from the Swedish Institute. During the meeting, on December 1st 2020, the Crown Princess and Prince Daniel were given an update on the image of Sweden abroad and on the Institute's current issues due to the pandemic.
The meeting, with the Director-General of the Institute, Madeleine Sjöstedt, also saw the royals chat to Sofia Bard and Emma Jansson, about their experiences in the pandemic. This meeting was a follow-up to one that took place between the Crown Princess and the Institute in April this year.
On 16 April, the Crown Princess and Prince Daniel held digital meetings with the Swedish Institute and Professor Lars Trägårdh to receive updated information about the Covid-19 pandemic. The couple then also talked to Professor Lars Trägårdh, who is researching trust. Under the prevailing circumstances, when everyday life changes for many people, Trägårdh reported on how trust and confidence in social institutions are affected in different ways and for the outside world's view of Sweden's handling of the Covid-19 pandemic.
The Swedish Institute works to increase interest and strengthen confidence in Sweden abroad. One of the institute's main assignments is also about following and analysing how Sweden is perceived abroad. Within its framework is the examination of the image of Sweden in different parts of the world.
The Crown Princess has a long tradition of collaborating with the Swedish Institute and being updated by the Institute with information on how Sweden is perceived in the world. The head of the Institute and representatives have been received in audience with the Crown Princess at the palace in Stockholm many times in recent years.
Sweden's response to the pandemic has been the subject of intense international debate and has led to some friction between the Kingdom of Sweden and its immediate neighbours, the Kingdom of Norway, the Kingdom of Denmark and the Republic of Finland. The fear of imported Covid-19 infection from Sweden to other European nations has been great and there are still closed and guarded borders between Sweden and all the nation's neighbouring countries.


text:
Q: Dynamic import style and set scss variable value I have an admin template in which I would like user to provide option to switch between different theme color such as dark/light theme along with setting variable values, but I'm unable to conditionally import style files.
@if $light-theme {
    @import "./_metronic/_assets/sass/themes/layout/aside/light.scss";
    $primary: green;
} @else {
    @import "./_metronic/_assets/sass/themes/layout/aside/dark.scss";
    $primary: blue;
}

Getting error: Import directives may not be used within control directives or mixins.

A: Also it is a very long wished item to sass ... as the error message returns: that is not possible. (https://github.com/sass/sass/issues/279)
But what you can do is setting a theme variable and import your theme files. Every theme file has an conditional output based on the theme variable:
$theme: 'light-theme';
@import 'path/dark-theme';
@import 'path/light-theme';

// EVEREY THEME FILE WITH STRUCTURE:
@if( $theme == 'this-theme' ){

   /*
      here goes your theme variables or
      if whanted your theme code in the file
   */

}