#  SightSteeple:
Agreeing to Disagree with Functional Blockchain Consensus

Aditya Ahuja  Indian Institute of Technology DelhiNew DelhiIndia
<EMAIL_ADDRESS>
(2022)

###### Abstract.

Classical and contemporary distributed consensus protocols, may they be for
binary agreement, state machine replication, or blockchain consensus, require
all protocol participants in a peer-to-peer system to agree on exactly the
same information as part of the consensus payload. Although this model of
consensus is extensively studied, and is useful for most consensus based
decentralized applications, it falls short of defining correct distributed
systems which mandate participant credential based privileged visibility into
the consensus payload, through the consensus protocol itself.
We introduce a new paradigm for distributed consensus, called _functional
blockchain consensus_. Functional blockchain consensus allows each blockchain
protocol participant to agree on some distinct sub-information of the list of
transactions, as a function of the credentials of the participant in the
blockchain system, instead of agreeing on the entire list of transactions. We
motivate two adversary models, one with a standard crash-fault adversary and
another with a novel rational-fault adversary, to compromise functional
blockchain consensus. We then present two versions of a blockchain protocol
called SightSteeple, that achieves functional blockchain consensus in the said
fault models. SightSteeple relies on a novel combination of standard
blockchain consensus and functional encryption, among other primitives, to
achieve its goals of correctness. Finally, we discuss practical uses of
functional blockchain consensus based asymmetric distributed ledgers, and
motivate off-shoot constructions that can result from this new consensus
paradigm.

Functional Blockchain Consensus, Hierarchical Blockchains

††copyright: acmcopyright††journalyear: 2022††conference: ; ; ††ccs: Security
and privacy Distributed systems security††ccs: Security and privacy
Cryptography

##  1\. Introduction

Distributed consensus, which can manifest in the form of binary agreement
(Dolev and Strong, 1983; Shi, 2020), state machine replication (Yin et al.,
2019; McMenamin et al., 2021), or blockchain consensus (Bano et al., 2019;
Xiao et al., 2020; Chan and Shi, 2020), requires a set of networked processes
to agree on some information. In each manifestation, the notion of consensus
is to agree on an identical snapshot of the information as part of the
consensus payload, symmetrically, by each of the processes involved. Although
this notion of consensus may be useful for symmetric information based
decentralized applications, it precludes decentralized applications requiring
consensus on sensitive information, where there is a need for privileged
visibility into the consensus payload for each of the participant processes.
From a pedagogical perspective, there is a lack of consensus paradigms and
protocols where visibility into the consensus payload is predicated on the
credentials of the consensus protocol participants. Presently, distributed
consensus is in general defined for a peer-to-peer system, and to
intentionally preclude the credentials that the consensus protocol
participants may possess: those credentials, which may define the privilege of
their visibility into the consensus payload. Consequently, as at least an
academic exercise, there is a need for defining _paradigms for asymmetric
consensus_ : the consensus protocol participants may agree on some sub-
information, which is any information that may be inferred from the complete
consensus payload, as a function of their credentials in the distributed
system, once those credentials are established and agreed to in a
decentralized setting.
One way to achieve asymmetric consensus is to ensure that the information
contained in the consensus payload that is being considered by all processes
is identical, however the agreed _view_ 111We use ‘view’ to denote any sub-
information that can be implied by the complete information contained in the
consensus payload, and will formally define a view later. or summary of the
payload, and the consequential distributed ledger, is allowed to be different
for different processes, as long as there exists a _hierarchy of inference_
across the views of each of the processes. The hierarchy of inference should
necessitate that some views are implied by other views, thereby ensuring an
asymmetric consistency across all processes. Such credential based consensus
definitions and protocols for secure consensus payload views for each of the
involved processes (similar to secure information flow (Denning, 1976)),
resulting in continuously growing logs which are the output of the consensus
protocol, do not exist yet to the best of our knowledge.
There is also a practical motivation for asymmetric consensus based
decentralized applications. For instance, cryptocurrencies (Bonneau et al.,
2015) with sensitive transactions may require asymmetric distributed ledgers,
which allow different processes to see different summaries of the list of
transactions, or allow processes to learn the list of transactions only when
certain preconditions are met. Decentralized finance (DeFi) (Werner et al.,
2021) applications may require hierarchical distributed ledgers for selective
portfolio exposure to enable asymmetrical access to automated markets. There
would also be, in general, a need for asymmetric records for agreement on
classified information in information critical decentralized sectors requiring
sensitive data distribution (Casino et al., 2019).222We motivate decentralized
applications based on functional blockchain consensus, in more detail, in
Section 6.1.
Given the explosion of blockchain based decentralized applications in recent
times (Casino et al., 2019), there is a motivation for blockchain based
information flow hierarchies in decentralized applications and organizations,
perhaps through separate yet hierarchical blockchains across the blockchain
protocol participants, especially in information critical sectors as
mentioned. Consequently, it is befitting and opportune to consider, both as an
academic exercise and a practical curiosity, asymmetric blockchain consensus
models and protocols, for defining hierarchical blockchains: models that
generalize standard blockchains by accommodating credential-based asymmetric
agreement on the list of transactions.

### Our Contributions

In this paper, we make the following contributions333Our contributions are
inspired from and are a refinement to a patent application on functional
blockchain consensus (Ahuja et al., 2021)..

_Introducing Functional Blockchain Consensus (Section 2)._ We present a player
model for consensus where blockchain protocol participants (or _players_) have
different credentials towards their visibility into the blockchain payload. We
formally define a block payload view, which is any information that can be
inferred from the complete list of transactions. We then introduce our new
paradigm of consensus, called _functional blockchain consensus_ , which, given
the credentials of all players in the blockchain system, allows (i) each
honest player to agree on a distinct block payload view, as a function of its
credentials in the system, and (ii) allows each honest player to know that its
honest counterparts agree on a correct block payload view. Functional
blockchain consensus may result in different blockchains for different players
(with some blockchains being implied by other blockchains), and so we formally
show that functional blockchain consensus is a generalization of traditional
blockchain consensus.

_Presenting SightSteeple under a fail-stop adversary (Section 4)._ Given a a
partially synchronous network (Dwork et al., 1988) with crash-fault adversary
that controls less than half of the players in the system, we present our
first functional blockchain consensus protocol called SightSteeple-CFT.
SightSteeple-CFT is constructed by amending the crash-fault tolerant version
of the streamlined Streamlet (Chan and Shi, 2020) blockchain protocol, and by
using functional encryption for all efficiently computable functions (Garg et
al., 2014) (among other cryptographic primitives).

_Presenting SightSteeple under an economically incentivized, payload view
compromise adversary (Section 5)._ We motivate a new adversary model under
functional blockchain consensus, termed a _rational_ adversary. A rational
adversary, apart from maximizing its revenue through the consensus protocol
(which may include any combination of block rewards, transaction fees, or
double spending transactions), would simultaneously want to maximize its block
payload view and try to learn the complete list of transactions instead of
some summary of it. To that end, the adversary would be willing to mislead the
honest players towards learning incorrect payload views. Under a rational
adversary controlling less than one-third of the players in the system, over a
partially synchronous network, we present our next protocol called
SightSteeple-RFT. SightSteeple-RFT is constructed by amending the Byzantine-
fault tolerant version of Streamlet, and by using verifiable functional
encryption schemes (Badrinarayanan et al., 2016).

#### Our goals, and open problems.

In this work, we intend to initiate the study of hierarchical visibility into
the blockchain payload, through a new functional blockchain consensus
protocol. We discuss the impossibility of Byzantine-fault tolerant
SightSteeple (Section 5.1). We will not give exact construction of any
functional encryption scheme, but point out their existence and viability for
various distributed ledgers (Section 6.1). We will discuss the subtleties of
privilege alteration attacks, both on-chain and off-chain, and point to
possible solutions to harden the protocol (Section 6.2). We will motivate
future definitions on asymmetric smart contracts and alternate asymmetric
consensus paradigms, such as consensus on transaction declassification, which
might have a construction similar to SightSteeple (Section 7).

### Related Work

_Asymmetric trust, and relaxing consensus_. There have been proposals to model
asymmetric Byzantine quorum systems over an asynchronous network, where each
consensus protocol participant is free to choose which participants it
considers faulty, and which it considers honest (non-faulty) (Cachin, 2021),
and consequential consensus protocols have been proposed (Cachin and Zanolini,
2021). There have been proposals to relax the definition of consensus (more
specifically, relaxing the definition of termination within consensus) in
blockchains, over an asynchronous network (Sliwinski and Wattenhofer, 2019).
None of these contributions permit an asymmetric _visibility_ of the consensus
payload, nor advocate for asymmetry on the agreed information for the
participants in the protocol.
_Hybrid blockchains_. Hybrid blockchains, which have a public chain and
multiple private subchains to realize the decentralized application (Zhu et
al., 2019; Cui et al., 2020a), are different from SightSteeple where
blockchain payload visibility can change for each player on the same chain.
_Solutions at the intersection of blockchains and functional encryption_.
There have been proposals to outsource decryption under a functional scheme,
with incentivization, to blockchains (Cui et al., 2020b). Privacy preserving
energy trading in blockchain empowered smart grids has been proposed by
leveraging functional encryption (Son et al., 2020). Secure distributed smart
meters have been defined using a combination of blockchains and functional
encryption (Yurchenko et al., 2020). A power efficient elliptic curve pairing
crypto-processor has been proposed for blockchains and functional encryption
(Banerjee and Chandrakasan, 2021). None of these contributions define a
consensus model that can be realized using a combination of standard
blockchains and functional encryption, which is central to our contribution.

##  2\. Functional Blockchain Consensus

In this section, we introduce functional blockchain consensus.

###  2.1. The Player Model

We refer to the blockchain protocol participants, which are (polynomial-time)
interactive Turing machines, as _players_. The set of players is given by
$[n]:=\\{1,2,...,n\\}$, where some players are honest (non-faulty) and others
are faulty. Further, each player $i\in[n]$ has some credentials
$\kappa_{i}\in\\{0,1\\}^{*}$, with the highest credential denoted by
$\kappa^{*}$. Let $\mathcal{C}=(\kappa_{i})_{i\in[n]}$ denote the list of
credentials for all players.
Further, there exists a third party for trusted setup, called init-party, that
does not participate in consensus, but distributes the credentials to each
player.

###  2.2. Block Payload View

We first introduce a block payload _view_ , which has a special connotation in
functional blockchain consensus (not to be confused with view change in state
machine replication, or a real-time snapshot of the blockchain state in
standard blockchains (Chan and Shi, 2020)). A block payload view for a
specific player in functional blockchain consensus, is the sub-information of
the list of transactions that the said player agrees upon, and includes in its
blockchain. We formalize this through the following definition.

Definition 1 (Block Payload View). _A set of functions $\mathbb{F}$ is a set
of block payload view functions iff
$\forall\textsf{txs}\in\\{0,1\\}^{*},\forall f\in\mathbb{F}$,
$f(\textsf{txs})$ is implied by txs. Further there exists an identity function
$f^{*}\in\mathbb{F}$, such that
$\forall\textsf{txs}\in\\{0,1\\}^{*},f^{*}(\textsf{txs})=\textsf{txs}$, and a
null function $f_{\bot}\in\mathbb{F}$, such that
$\forall\textsf{txs}\in\\{0,1\\}^{*},f_{\bot}(\textsf{txs})=\bot$.
Further, $\forall\textsf{txs}\in\\{0,1\\}^{*},\forall f\in\mathbb{F}$, we call
$f(\textsf{txs})$ a block payload view of txs under view function $f$._

_Examples of block payload views._ Instances of block payload views include
view functions that provide the smallest transaction in the list of
transactions, or provide the sub-list of the transactions by a particular
transacting party (say Alice), or provide the sum of the tokens exchanged in
all the transactions in the transaction list.

_Mapping players’ credentials to their permissible payload view._ Given a
player with certain credentials, there needs to be a correspondence between
the player’s credentials and the view function (s)he is eligible for. Let
$\Psi:\\{0,1\\}^{*}\rightarrow\mathbb{F}$ be the function, determined by the
init-party, that provides this mapping. Also, it is true that
$\Psi(\kappa^{*})=f^{*}$.

###  2.3. Defining Functional Blockchain Consensus

Having presented the player model and introduced block payload views, we now
formally define functional blockchain consensus.

Definition 2 (Functional Blockchain Consensus). _Assume there exist $n$
players with credentials $\mathcal{C}$, and each player is eligible to learn a
block payload view under the view function set $\mathbb{F}$, through $\Psi$. A
blockchain protocol achieves ‘functional blockchain consensus’, if it attains
the following consensus goals (with all but negligible probability in the
security parameter), for each epoch $e$ of the blockchain system when the
block payload $\textsf{txs}^{e}$ is added consistently to the blockchain:_

_1\. Functional Hierarchy Consistency: For each honest player $i\in[n]$,
player $i$ agrees on $(\Psi(\kappa_{i})=f^{e}_{i}\in\mathbb{F})_{i\in[n]}$._

_2\. Block Payload View Integrity: For each honest player $i\in[n]$, player
$i$ agrees on $f^{e}_{i}(\textsf{txs}^{e})$, and $i$ knows that each honest
player $j\in[n],j\neq i$ agrees on $f^{e}_{j}(\textsf{txs}^{e})$. Further, if
for some honest player $i\in[n]$,
$f^{e}_{i}(\textsf{txs}^{e})=f^{*}(\textsf{txs}^{e})=\textsf{txs}^{e}$, then
$i$ verifies that $\textsf{txs}^{e}$ is valid (does not contain double
spending transactions)._

_3\. Liveness: If some honest player with highest credentials receives a valid
block payload $txs$ in some round, that payload will eventually be summarized
and finalized in each honest player’s blockchain._

It is instructive to give an explanation of Definition 2. In the first
requirement for achieving functional blockchain consensus, each honest player
must agree that each player in the system is eligible for a block payload view
congruent to its credential in the system. In the second requirement, it is
ensured that each honest player knows that each honest player did indeed learn
a block payload view in accordance with its view function. In the final
requirement, it is just ascertained that every valid block payload eventually
goes on-chain.

Kindly note that in the most general case, the credentials of each player can
be a function of time (which means that the correct payload view function of
the players can be a function of time).

###  2.4. Hierarchical Player Blockchains

We introduce some terminology first. We say a payload view is _notarized_
444An equivalent notion of a notarized block, is a mined block in Nakamoto
consensus blockchains (Bonneau et al., 2015). (similar terminology in
Streamlet (Chan and Shi, 2020)), once it receives a threshold of votes from
some of the players and is eligible to be eventually confirmed in the player’s
blockchain. We say that a notarized payload view is _finalized_ once is is
confirmed as a part of the player’s blockchain.
For each player $i\in[n]$, and an arbitrary epoch $e$, the player’s blockchain
under functional blockchain consensus, is given by
$\textsf{chain}^{e}_{i}:=(\textsf{chain}^{e-1}_{i},H^{*}(f^{e^{\prime}}_{i}(\textsf{txs}^{e^{\prime}})),f^{e}_{i}(\textsf{txs}^{e}))$,
with $e^{\prime}<e$, notarized $f^{e}_{i}(\textsf{txs}^{e})$ linked to
notarized $f^{e^{\prime}}_{i}(\textsf{txs}^{e^{\prime}})$, and
$\textsf{chain}^{0}_{i}$ is the genesis block. The standard blockchain, which
is ideal (corresponding to the payload view function $f^{*}$), is given by
$\textsf{chain}^{*,e}:=(\textsf{chain}^{*,e-1},H^{*}(\textsf{txs}^{e^{\prime}}),\textsf{txs}^{e})$,
similarly. Note that each player’s notarized blockchain might be a block-tree
in general, with the finalized blockchain being a sub-chain of the notarized
block-tree. We will denote each player $i$’s finalized blockchain by
$\textsf{chain}_{i}$, and the ideal finalized blockchain by
$\textsf{chain}^{*}$ (dropping the epoch superscript).

_View Functions’ Hierarchy._ We first define the binary relation $\preceq$
over the set of credentials. $\forall i_{1},i_{2}\in[n]$,
$\kappa_{i_{1}}\preceq\kappa_{i_{2}}$ implies that player $i_{2}$ has no
lesser credentials than player $i_{1}$, and consequently for each epoch $e$,
payload view $\textsf{txs}^{e}_{i_{1}}=f_{i_{1}}(\textsf{txs}^{e})$ should be
implied by payload view
$\textsf{txs}^{e}_{i_{2}}=f_{i_{2}}(\textsf{txs}^{e})$. This is denoted
equivalently with $f_{i_{1}}\preceq f_{i_{2}}$, or even
$\textsf{chain}_{i_{1}}\preceq\textsf{chain}_{i_{2}}$. From Definition 1, it
is evident that $\forall f\in\mathbb{F},f_{\bot}\preceq f\preceq f^{*}$.
It is easy to see that $(\mathbb{F},\preceq)$ is a partial order, as the
binary relation $\preceq$ over $\mathbb{F}$ is reflexive, anti-symmetric and
transitive555This partial order provides the hierarchy of inference on the
consensus payload, which was mentioned in Section 1.. $\forall
f_{1},f_{2}\in\mathbb{F}$, define $\textsf{dist}_{\preceq}(f_{1},f_{2})$ to be
the number of functions on the path between $f_{1}$ and $f_{2}$ in the partial
order $(\mathbb{F},\preceq)$. From Definition 1, it is evident that $\forall
f_{1},f_{2}\in\mathbb{F},\textsf{dist}_{\preceq}(f_{1},f_{2})\leq\textsf{dist}_{\preceq}(f_{\bot},f^{*})$.
For some $S\subseteq[n]$, define
$\inf_{\preceq}\\{f_{i}(\textsf{txs})\\}_{i\in
S}:=\\{f_{j}(\textsf{txs})\\}_{j\in S^{*}}$ to be the smallest
$S^{*}(\subseteq S)$ such that for each $f_{i}(\textsf{txs})\in S$, there
exists $f_{j}(\textsf{txs})\in S^{*}$ such that $f_{j}\preceq f_{i}$.
Similarly, for some $S\subseteq[n]$, define
$\sup_{\preceq}\\{f_{i}(\textsf{txs})\\}_{i\in
S}:=\\{f_{j}(\textsf{txs})\\}_{j\in S^{*}}$ to be the smallest
$S^{*}(\subseteq S)$ such that for each $f_{i}(\textsf{txs})\in S$, there
exists $f_{j}(\textsf{txs})\in S^{*}$ such that $f_{i}\preceq f_{j}$.

_Hierarchical player blockchains generalize standard blockchains._ $\forall
i\in[n],\forall e$, if it is the case that $f^{e}_{i}=f^{*}$, then it is true
that each honest player’s payload view is identical and contains all the
transactions for each block in each epoch: $\forall
e,i\in[n],\textsf{chain}_{i}=\textsf{chain}^{*}$. In this instance, each
player’s blockchain under functional blockchain consensus is no different than
a standard blockchain.

###  2.5. Alternate Functional Consensus Models

We briefly discuss possibilities of asymmetric consensus in binary agreement
and state machine replication, which can be considered in the context of
functional blockchain consensus.

_Functional Binary Agreement reduces to Binary Agreement._ Binary agreement
requires a set of processes to agree on a bit. Firstly, note that, binary
agreement on constant functions on a bit do not require a consensus protocol.
In case binary agreement is considered on non-constant functions on a bit, it
can be proved that all non-constant functions on a bit are invertible, and so
consequently any functional binary agreement definition can be reduced to
standard binary agreement.

_Functional Blockchain Consensus and Functional State Machine Replication
Consensus are equivalent._ State machine replication is a method for providing
a fault-tolerant service where replicas of servers maintain the correct state
of the service, and accept commands from clients to update the state of the
service. There are direct parallels between functional blockchain consensus
and a possible ‘functional’ consensus for state machine replication: block
payload view is equivalent to a sub-state (a sub-automaton) of the service.
Thus, by replacing the list of transactions txs (the blockchain payload) with
state (the state of the system) and by replacing block payload view functions
in $\mathbb{F}$ with state machine sub-state functions in $\mathbb{F}$, in
Definitions 1 and 2, an equivalent definition of functional state machine
replication can be proposed.

##  3\. Preliminaries

We first present the preliminary assumptions and constructions required by the
SightSteeple protocols.

###  3.1. The Execution Model

_The Player Model._ We assume that the players $[n]$ are ordered with non-
increasing static credentials, by the init-party: $\forall
i_{1},i_{2}\in[n],i_{1}\leq i_{2}$, $\kappa_{i_{1}}\preceq\kappa_{i_{2}}$. We
denote the subset of players that can participate in block proposal (defined
in Section 3.3) by $[m]$, where $m\leq n$. $\forall
i\in[m],\kappa_{i}=\kappa^{*}$, and $\forall
j\in\\{m+1,m+2,...,n\\},\kappa_{j}\prec\kappa^{*}$ ($j$ has lower than highest
credentials). We refer to all the players in $[m]$ as _head_ players.

_Credentials’ Initialization._ The init-party is a trusted benevolent body
that initializes the system by distributing the credentials, does not
participate in consensus, and cannot flag adversarial players. During setup,
the init-party makes $\Psi$ public. Each player $i\in[n]$ only knows its
$\kappa_{i}$ through the init-party, unless $\kappa_{i}=\kappa^{*}$, in which
case $i$ knows $\mathcal{C}$ through the init-party.

_The Network Model._ We assume that there exists a permissioned, authenticated
blockchain network of $n$ players. We assume that the clocks of all players
are synchronized, and block proposal occurs in epochs. We assume that the
network obeys partial synchrony (Dwork et al., 1988), where, there exists a
known finite number of rounds $\Delta$, and an unknown Global Stablization
Time $GST$, such that for any message sent by any honest player at round
$r_{0}$, the said message is received by all honest players in $[n]$ by round
$\max(r_{0},GST)+\Delta$. We ignore the impact of computation times of
cryptographic routines on our message delays (as in our base protocol
Streamlet (Chan and Shi, 2020)).

_The Fault Model._ We assume there exists an unknown, static partition of
$[n]$, of honest and faulty players $(\mathcal{H},\mathcal{A})$. The honest
players in $\mathcal{H}$ follow the protocol specification as is, and the
faulty players in $\mathcal{A}$ deviate from the specified protocol under the
failure types stated next.
We assume that given the static adversary, there is at least one head player
that is not compromised by it: at least one player in $[m]$ is honest, to
eliminate the possibility of double-spending by the adversary (will be
discussed in detail in Section 5.4). We will first consider the traditional
crash-fault adversary: once a player is compromised by the adversary, it stops
sending and received all protocol specific messages. We will then define a
novel _rational-fault_ adversary under the functional blockchain consensus
paradigm: briefly, a rational adversary would try to maximize its revenue from
participation in the consensus protocol, and simultaneously try to maximize
its visibility in the blockchain payload (the list of transactions). We cover
each adversary in detail in the relevant sections that follow.

###  3.2. Streamlet: The Base Protocol

SightSteeple will be an amendment to the streamlined blockchain protocol
Streamlet (Chan and Shi, 2020). Streamlet will be considered over a partially
synchronous network, with one of crash-fault or Byzantine-fault adversaries.
For each block, consensus in Streamlet takes place in four stages: block
proposal, block vote, block notarization (when the block receives a threshold
of votes), and block finalization (when the block is confirmed). These four
stages will be revised and re-interpreted in SightSteeple. For details on
Streamlet, please see Appendix A.1.

###  3.3. Metablocks, Metachain and Player Blockchains

_The Metablock._ In SightSteeple, we introduce a ‘metablock’ as a super block
containing encrypted information about the block payload (the list of
transactions txs). Each player can selectively read part of the information
contained in the metablock, as per its privileges towards the block payload.
Since only head players have the highest credentials in the SightSteeple
system, metablocks can solely be proposed by them. We will denote, for each
epoch $e$, the metablock using $\textsf{M}^{e}$.
_The Metachain._ The ‘metachain’ would simply be the blockchain of metablocks.
We would denote, for each epoch $e$, the presently notarized metachain by
$\textsf{mchain}^{e}$ (which may be a tree of metablocks), and the final
metachain at any epoch by mchain.

_Player Blockchains are implied by the SightSteeple Metachain._ Since each
metablock in the metachain contains information that can be selectively
inferred by each player, based on the encrypted information on the list of
transactions as part of the metablock, each honest player $i\in[n]$ can deduce
$\textsf{chain}^{e}_{i}$ from $\textsf{mchain}^{e}$, for each epoch $e$.

###  3.4. Basics of Functional Encryption

Functional encryption will be extensively employed in SightSteeple to
preferentially reveal information to each player as part of each metablock.
Under a functional encryption scheme (Boneh et al., 2011), given the
encryption of a message $\textsf{msg}\in\\{0,1\\}^{*}$, the decryptor can
recover $f(\textsf{msg})$ if provided with the secret key $sk_{f}$ under the
scheme by the encryptor for a particular function $f$. Under a verifiable
functional encryption scheme (Badrinarayanan et al., 2016), the decryptor can
validate $f$ from the supplied secret key for decryption, and recover $f(m)$,
even if the encryptor is faulty (malicious), and wants to fool the decryptor
by supplying a key $sk_{f^{\prime}}$ for some $f^{\prime}\neq f$. A functional
encryption scheme for all circuits (Garg et al., 2014) supports the functional
encryption of all efficiently computable functions over the message space
$\\{0,1\\}^{*}$. We will denote the set of all efficiently computable
functions as $\mathbf{\hat{F}}$. It is easy to see that
$\mathbb{F}\subseteq\mathbf{\hat{F}}$. For details on functional encryption,
please see Appendix A.2.

###  3.5. Notation

Let $e$ denote an epoch of the metachain, and simultaneously that of each
player chain. $L_{e}$ will denote the metablock proposing epoch leader, and is
a random member of $[m]$. Let $H^{*}$ denote a collision resistant hash
function, which is ideal under the random oracle model (its image is uniformly
distributed). Let $\Gamma_{\text{Sig}}$ denote a signature scheme,
$\Gamma_{\text{E}}$ denote a public key encryption scheme,
$\Gamma_{\text{aFE}}$ (Garg et al., 2014) denote a functional encryption
scheme for all efficiently computable functions, and $\Gamma_{\text{vFE}}$
(Badrinarayanan et al., 2016) denote a verifiable functional encryption
scheme.

Given a message $\textsf{msg}\in\\{0,1\\}^{*}$, define signed message under
scheme $\Gamma_{\text{Sig}}$ by player $i$ as
$(\textsf{msg})_{\Gamma_{\text{Sig}}.i}$ and encrypted message under scheme
$\Gamma_{\text{E}}$ for player $i$ as
$(\textsf{msg})_{\Gamma_{\text{E}}.{i^{-1}}}$.

Crash-fault tolerant Streamlet will be denoted by $\Pi^{0}_{\text{cft}}$, and
Byzantine-fault tolerant Streamlet will be denoted by $\Pi^{0}_{\text{bft}}$.
The crash-fault tolerant SightSteeple protocol will be denoted by
$\mathbf{\Pi}^{\text{ss}}_{\text{cft}}$, and the rational-fault tolerant
version will be denoted by $\mathbf{\Pi}^{\text{ss}}_{\text{rft}}$.

We will use $\textrm{M}.$Add$-\textsf{msg}$ to denote the addition of a
message $\textsf{msg}\in\\{0,1\\}^{*}$ to metablock M.

##  4\. SightSteeple: Crash Fault Tolerant

We present the first version of the SightSteeple functional blockchain
consensus protocol, in the presence of a _crash-fault_ adversary
$\mathcal{A}$: all adversarial players stop sending and receiving all messages
related to the the protocol. We assume $|\mathcal{A}|<\frac{n}{2}$.

###  4.1. Metablock Structure

_The genesis block._ The players in $[n]$ initialize the system by agreeing on
the genesis block
$\textsf{gen}:=(0,[n],\mathcal{C},\mathbb{F},\Psi,\Gamma_{\text{E}},\Gamma_{\text{aFE}},H^{*})$.
The genesis block is notarized when at least $\frac{n}{2}$ players vote on it
(a vote by a player is just a signed hash of the genesis block by that
player).

_The metablock._ The metablock for SightSteeple-CFT is presented next. In
brief, the metablock contains the current epoch number $e$, hash of the
previous metablock $\mathrm{M}^{e^{\prime}}$ to which the current metablock is
linked, encryption of the list of transactions $\textsf{txs}^{e}$ under
$\Gamma_{\text{aFE}}$, and, for each player $i$, hash of the current player
chain $\textsf{chain}_{i}^{e-1}$, payload view function $f^{e}_{i}$ for $i$,
and the encryption of the secret key $\textrm{sk}_{f^{e}_{i}}$ under
$\Gamma_{\text{aFE}}$, recoverable by $i$.

SS-CFT Metablock: The Contents of $\mathcal{M}^{e}_{\mathcal{H}}$ (by Leaders
in $\mathcal{H}$) Initialize $\mathcal{M}^{e}_{\mathcal{H}}\leftarrow\phi$
$\mathcal{M}^{e}_{\mathcal{H}}.$Add$-(e,H^{*}(\mathrm{M}^{e^{\prime}}),\Gamma_{\text{aFE}}.\textrm{Enc}_{\textrm{pp}^{e}}(\textsf{txs}^{e}))$
$\forall i\in[n]$:
$\mathcal{M}^{e}_{\mathcal{H}}.$Add$-(i,H^{*}(\textsf{chain}_{i}^{e-1}),f^{e}_{i},(\Gamma_{\text{aFE}}.\textrm{sk}_{f^{e}_{i}})_{\Gamma_{\text{E}}.i^{-1}})$

###  4.2. The SightSteeple-CFT Protocol

The SightSteeple-CFT Protocol $\mathbf{\Pi}^{\text{ss}}_{\text{cft}}$ is
presented in Algorithm 1.

#### Protocol Outline

For each epoch, the metablock proposing leader is elected as a random member
of $[m]$, as a function of $e$. If the leader is honest, it proposes
$\mathcal{M}^{e}_{\mathcal{H}}$ to the network (otherwise, no metablock is
proposed). On successfully receiving the metablock, the honest players in
$[n]$ reply by broadcasting their vote (denoted by $\textrm{V}^{e}_{i},\forall
i\in[n]$) over the network. The metablock is notarized once it achieves a vote
from at least all the honest players. The metablock is finalized according to
the finalization rule of the crash-fault tolerant version of Streamlet
$\Pi^{0}_{\text{cft}}$ (Sec. 5 in (Chan and Shi, 2020)).

Algorithm 1: SightSteeple-CFT ($\mathbf{\Pi}^{\text{ss}}_{\text{cft}}$) Leader
Election: $\forall e,L_{e}:=H^{*}(e)\mod m$ Metablock Proposal: If
$L_{e}\in\mathcal{H},\textrm{M}^{e}=\mathcal{M}^{e}_{\mathcal{H}}$. If
$L_{e}\in\mathcal{A},\textrm{M}^{e}=\bot$. $\forall e,L_{e}$ broadcasts
$\textrm{M}^{e}$ Metablock Vote: $\forall i\in[n]$, $i$ broadcasts
$\textrm{V}^{e}_{i}=(i,e,H^{*}(\textrm{M}^{e}))$. Metablock Notarization:
$\textrm{M}^{e}$ is notarized when at least $\frac{n}{2}$ players vote for it.
Metablock Finalization (from Streamlet $\Pi^{0}_{\text{cft}}$): If in any
notarized metachain, there exist three hash-linked metablocks with consecutive
epoch numbers, the prefix of the metachain up to the second of the three
metablocks is considered final. Further, when a metablock is finalized, its
parent chain is also finalized.

####  4.2.1. Correctness

We show that the SightSteeple-CFT protocol is correct.

Theorem 3 (SS-CFT Correctness). _The SightSteeple-CFT protocol
$\mathbf{\Pi}^{ss}_{\text{cft}}$ achieves functional blockchain consensus, in
the presence of a crash-fault adversary $\mathcal{A}$, with
$|\mathcal{A}|<\frac{n}{2}$._
_Proof._ Since the notarization and finalization rules in
$\mathbf{\Pi}^{ss}_{\text{cft}}$ are equivalent to those in
$\Pi^{0}_{\text{cft}}$, the $\mathbf{\Pi}^{ss}_{\text{cft}}$ metachain will be
consistent across all players (Theorem 12 in (Chan and Shi, 2020)). We will
now show that $\mathbf{\Pi}^{ss}_{\text{cft}}$ achieves the three goals of
functional blockchain consensus (Definition 2), considering a consistent
metablock $\textrm{M}^{e}$ from an arbitrary epoch $e$, and remembering the
metablock response from honest leaders is $\mathcal{M}^{e}_{\mathcal{H}}$ and
crash-faulty leaders do not propose a metablock:

(i) Functional Hierarchy Consistency: Since all honest players vote on the
genesis block which contains $([n],\mathcal{C},\mathbb{F},\Psi)$, and vote on
the metablock $\textrm{M}^{e}$ which contains $(f^{e}_{i})_{i\in[n]}$, it is
implied that all honest players agree on
$(\Psi(\kappa_{i})=f^{e}_{i}\in\mathbb{F})_{i\in[n]}$.

(ii) Block Payload View Integrity: Since each honest player voted on the
metablock, which implies that it successfully received $\textrm{M}^{e}$, it is
true that each honest player knows that each honest player $i\in[n]$ agrees on
$f^{e}_{i}(\textsf{txs}^{e})$. Further, since each honest head player voted,
it is true that $\textsf{txs}^{e}$ doesn’t contain double spending
transactions.

(iii) Liveness: The $\mathbf{\Pi}^{ss}_{\text{cft}}$ metablock finalization
rule is identical to the $\Pi^{0}_{\text{cft}}$ block finalization rule. Thus,
the liveness of $\mathbf{\Pi}^{ss}_{\text{cft}}$ is implied by Theorem 13 in
(Chan and Shi, 2020) (details in Appendix A.1). $\hfill\square$

#### The $\mathbf{\Pi}^{\text{ss}}_{\text{cft}}$ metachain implies each player
chain

Consider, for any epoch $e$, the metachain $\textsf{mchain}^{e}$ and the most
recent metablock $\textrm{M}^{e}$ in it. Also consider, for each honest player
$i\in[n]$, the sub-metablock $\textrm{M}^{e}_{i}$ of $\textrm{M}^{e}$.
$\textrm{M}^{e}_{i}$ contains:
1\.
$(e,H^{*}(\mathrm{M}^{e^{\prime}}),\Gamma_{\text{aFE}}.\textrm{Enc}(\textsf{txs}^{e}))$
2\.
$(i,H^{*}(\textsf{chain}_{i}^{e-1}),f^{e}_{i},(\Gamma_{\text{aFE}}.\textrm{sk}_{f^{e}_{i}})_{\Gamma_{\text{E}}.i^{-1}})$
From both these messages, it is easy for player $i$ to imply
$\textsf{chain}^{e}_{i}=(\textsf{chain}^{e-1}_{i},H^{*}(f^{e^{\prime}}_{i}(\textsf{txs}^{e^{\prime}})),f^{e}_{i}(\textsf{txs}^{e}))$,
by recovering the encrypted secret key $\textrm{sk}_{f^{e}_{i}}$ under
$\Gamma_{\text{E}}$, followed by recovering $f^{e}_{i}(\textsf{txs}^{e})$
under $\Gamma_{\text{aFE}}$.

##  5\. SightSteeple: Rational Fault Tolerant

###  5.1. Impossibility of (Secret Key based) BFT SightSteeple

Asymmetric block payload visibility based on encrypted on-chain information as
part of the metablock, and a secret key per player, can never be Byzantine
fault tolerant. This is because an adversarial player can just broadcast its
secret key after the metablock finalization, thereby violating the payload
view integrity on any lower credential honest player. Due to this payload view
malleability post payload finalization, Byzantine-fault tolerant SightSteeple
is impossible, as is formalized by the following attack.

Attack 1 (SightSteeple-BFT). _Assume there exists a Byzantine player
$i^{\prime}\in\mathcal{A}$, and an honest player $i\in\mathcal{H}$, with
$\kappa_{i}\preceq\kappa_{i^{\prime}}$ and
$\kappa_{i^{\prime}}\npreceq\kappa_{i}$. Assume at some epoch $\tilde{e}>e$,
the metablock $\textsf{M}^{e}$ is finalized, then player $i^{\prime}$ can
violate the block payload view integrity of player $i$ for epoch $e$, by
broadcasting $\Gamma_{\text{vFE}}.sk_{f^{e}_{i^{\prime}}}$ over the network at
epoch $\tilde{e}$._

Consequently, SightSteeple need be proposed for a weaker adversary.

###  5.2. Rational-fault Adversary: Motivation and Definition

We consider rational players which wish to (i) maximize their revenue from the
block payload, in terms of block reward (if the protocol is incentivized, as
in Bitcoin (Bonneau et al., 2015)), transaction fees, and by double spending
transactions in the payload which they are a part of; and (ii) maximize their
payload view (under $\preceq$).

Further, rational players may want to mislead honest players by supplying them
a secret key (under the functional encryption scheme) for an incorrect view
function, thereby forcing them to agree to an incorrect view of the payload,
and violating the block payload view integrity for honest players, even when
the metachain is consistent. An example to illustrate such an attack on head
players is given below. Consequence for honest head players under such an
attack is that they cannot propose payloads after the attack (as payloads may
not be notarizable), inducing an effective denial-of-service (different from
conventional DoS attacks as in (Mirkin et al., 2020)). Thus it is imperative
to design a protocol with verifiable view function keys for resilience to a
rational adversary.

Attack 2 (SightSteeple-RFT without $\Gamma_{vFE}$). _Let
$\tilde{f}(\textsf{txs}):=\textsf{txs}\text{ with reduced value of each tx by
1 unit}$. Consider, for some epoch $e$, a rational leader
$L_{e}=i^{\prime}\in\mathcal{A}$ supplies $sk_{\tilde{f}}$ instead of
$sk_{f^{*}}$ to an honest $i\in[m]$. Now, for the smallest $e^{\prime}>e$,
with $L_{e^{\prime}}=i$, if $i$ proposes a metablock containing payload
$\textsf{txs}^{e}$, the said metablock will not be notarized by any honest
head player (due to the impression of double spending)._

_Rational Players’ Utility Function._ We present the utility of the rational
adversary $\mathcal{A}$, which is a function of the metablock proposed and
notarized in the current epoch $e$. Briefly, the utility function is a convex
combination of the revenue $\tau_{\mathcal{A}}$ for the adversary resulting
from the potential confirmation of the payload $\textsf{txs}^{e}$ (which could
be any combination of block reward, if the consensus protocol is incentivized,
transaction fees, or transactions by the adversary in the payload), and the
visibility into the payload given by the payload view function
$f^{e}_{i^{\prime}}$ for each faulty player $i^{\prime}$. We give the
normalized utility function $v^{e}_{\mathcal{A}}$ next, where
$\beta_{1},\beta_{2}\in(0,1)$, with $\beta_{1}+\beta_{2}=1$:
$v^{e}_{\mathcal{A}}(\textrm{M}^{e}):=\beta_{1}\cdot\tau_{\mathcal{A}}(\textsf{txs}^{e})+\beta_{2}\cdot\frac{1}{|\mathcal{A}|}\sum_{i^{\prime}\in\mathcal{A}}\frac{\textsf{dist}_{\preceq}(f_{\bot},f^{e}_{i^{\prime}})}{\textsf{dist}_{\preceq}(f_{\bot},f^{*})}$
(1)

We assume that rational players wish to maximize their utility under
$v^{e}_{\mathcal{A}}$ from participation in rational-fault tolerant
SightSteeple, and so would choose metablock proposal strategies to that end.

###  5.3. Metablock Structure

_The genesis block._ The players in $[n]$ initialize the system by agreeing on
the genesis block
$\textsf{gen}:=(0,[n],\mathcal{C},\mathbb{F},\Psi,\Gamma_{\text{E}},\Gamma_{\text{vFE}},H^{*})$.
The genesis block is notarized when at least $\frac{2n}{3}$ players vote on it
(a vote by a player is just a signed hash of the genesis block by that
player).
We will modify the vote and notarization rule for the metablock.

_The metablock (by honest leaders)._ The metablock for SightSteeple-RFT by
honest leaders is presented next. The metablock contains the current epoch
number $e$, hash of the previous metablock $\mathrm{M}^{e^{\prime}}$ to which
the current metablock is linked, public parameters $\textrm{pp}^{e}$ under the
scheme $\Gamma_{\text{vFE}}$, encryption of the list of transactions
$\textsf{txs}^{e}$ under $\Gamma_{\text{vFE}}$, and, for each player $i$, hash
of the current player chain $\textsf{chain}_{i}^{e-1}$, payload view function
$f^{e}_{i}$ for $i$, and the encryption of the secret key
$\textrm{sk}_{f^{e}_{i}}$ under $\Gamma_{\text{vFE}}$, recoverable by $i$.

SS-RFT Metablock: The Contents of $\mathcal{M}^{e}_{\mathcal{H}}$ by Leaders
in $\mathcal{H}$ Initialize $\mathcal{M}^{e}_{\mathcal{H}}\leftarrow\phi$
$\mathcal{M}^{e}_{\mathcal{H}}.$Add$-(e,H^{*}(\mathrm{M}^{e^{\prime}}),\Gamma_{\text{vFE}}.\textrm{pp}^{e},\Gamma_{\text{vFE}}.\textrm{Enc}_{\textrm{pp}^{e}}(\textsf{txs}^{e}))_{\Gamma_{\text{Sig}}.L_{e}}$
$\forall i\in[n]$:
$\mathcal{M}^{e}_{\mathcal{H}}.$Add$-(i,H^{*}(\textsf{chain}_{i}^{e-1}),f^{e}_{i},(\Gamma_{\text{vFE}}.\textrm{sk}_{f^{e}_{i}})_{\Gamma_{\text{E}}.i^{-1}})_{\Gamma_{\text{Sig}}.L_{e}}$

_The metablock (by adversarial leaders)._ The metablock for SightSteeple-RFT
by rational leaders is also presented next. The metablock is the same as that
from the honest leaders, except that $\forall i\in\mathcal{A}$, the secret key
$\textrm{sk}_{f^{e}_{i}}$ under $\Gamma_{\text{vFE}}$ is replaced by
$\textrm{sk}_{f^{*}}$.

SS-RFT Metablock: The Contents of $\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$ by
Leaders in $\mathcal{A}$ Initialize
$\tilde{\mathcal{M}}^{e}_{\mathcal{A}}\leftarrow\phi$
$\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$.Add$-(e,H^{*}(\mathrm{M}^{e^{\prime}}),\Gamma_{\text{vFE}}.\textrm{pp}^{e},\Gamma_{\text{vFE}}.\textrm{Enc}_{\textrm{pp}^{e}}(\textsf{txs}^{e}))_{\Gamma_{\text{Sig}}.L_{e}}$
$\forall i\in[n]\setminus\mathcal{A}$:
$\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$.Add$-(i,H^{*}(\textsf{chain}_{i}^{e-1}),f^{e}_{i},(\Gamma_{\text{vFE}}.\textrm{sk}_{f^{e}_{i}})_{\Gamma_{\text{E}}.i^{-1}})_{\Gamma_{\text{Sig}}.L_{e}}$
$\forall i\in\mathcal{A}$:
$\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$.Add$-(i,H^{*}(\textsf{chain}_{i}^{e-1}),f^{e}_{i},(\mathbf{\Gamma_{\text{vFE}}.\textrm{sk}_{f^{*}}})_{\Gamma_{\text{E}}.i^{-1}})_{\Gamma_{\text{Sig}}.L_{e}}$

Note the need for a signature on metablock contents: a rational head player,
which is not the current epoch leader, can otherwise propose the metablock.

###  5.4. The SightSteeple-RFT Protocol

The SightSteeple-RFT Protocol $\mathbf{\Pi}^{\text{ss}}_{\text{rft}}$ is
presented in Algorithm 2. For this protocol, it is assumed that for the
rational adversary $\mathcal{A}$, $|\mathcal{A}|<\frac{n}{3}$.

#### Protocol Outline

For each epoch, the metablock proposing leader is elected as a random member
of $[m]$, as a function of $e$. If the leader is honest, it proposes
$\mathcal{M}^{e}_{\mathcal{H}}$ to the network. Otherwise, the rational leader
proposes $\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$. On receiving the the first
metablock from the leader, each honest player $i$ in $[n]$ validates its
contents to ensure that the secret key it received is that for
$\Psi(\kappa_{i})$. The honest head players also validate that
$\textsf{txs}^{e}$ has no double spending transactions. Post validation, the
honest players in $[n]$ reply by broadcasting their vote (denoted by
$\textrm{V}^{e}_{i},\forall i\in[n]$) to the network. Each vote is either a
‘yes’ vote if the validation succeeds, or a ‘no’ vote if the validation fails.
The metablock is notarized once it achieves a ‘yes’ vote from at least all the
honest players, and receives no ‘no’ votes. The metablock is finalized
according to the finalization rule of the Byzantine-fault tolerant version of
Streamlet $\Pi^{0}_{\text{bft}}$ (Sec. 3 in (Chan and Shi, 2020)).

#### Rational Player Voting Policy

We now show that it is not necessary for rational players to vote in order to
maximize their utility under $v^{e}_{\mathcal{A}}$, for any epoch $e$.

It is in the interest of rational players that, for the maximization of the
utility function $v^{e}_{\mathcal{A}}$, $\forall e,\textrm{M}^{e}$ is
notarized: if $\textrm{M}^{e}$ is not notarized, $v^{e}_{\mathcal{A}}=0$, but
if $\textrm{M}^{e}$ is notarized, there is a possibility that $\textrm{M}^{e}$
would be finalized, and consequently $v^{e}_{\mathcal{A}}>0$ (since
$\textsf{dist}_{\preceq}(f_{\bot},f^{e}_{i^{\prime}})>0,\forall
i^{\prime}\in\mathcal{A}$). This implies that for metablocks
$\mathcal{M}^{e}_{\mathcal{H}}$ and $\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$,
no rational player will ever vote no. Further, since honest players will
always vote ‘yes’ for $\mathcal{M}^{e}_{\mathcal{H}}$ and
$\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$, consequently both these metablocks
will be notarized, the rational players need not vote ‘yes’.

Algorithm 2: SightSteeple-RFT ($\mathbf{\Pi}^{\text{ss}}_{\text{rft}}$) Leader
Election: $\forall e,L_{e}:=H^{*}(e)\mod m$ Metablock Proposal: If
$L_{e}\in\mathcal{H},\textrm{M}^{e}=\mathcal{M}^{e}_{\mathcal{H}}$. If
$L_{e}\in\mathcal{A},\textrm{M}^{e}=\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$
$\forall e,L_{e}$ broadcasts $\textrm{M}^{e}$ Metablock Validation and Vote
(first $\textrm{M}^{e}$ from $L_{e}$): Each honest $i\in[n]$ asserts
$f^{e}_{i}=\Psi(\kappa_{i})$ and
$\textrm{sk}_{f^{e}_{i}}=_{\Gamma_{\text{vFE}}}\textrm{sk}_{\Psi(\kappa_{i})}$.
Each honest $i\in[m]$ also asserts $\textsf{txs}^{e}$ has no double spending.
If assertions succeed for $i$, broadcast
$\textrm{V}^{e}_{i}=(i,e,H^{*}(\textrm{M}^{e}),\text{yes})_{\Gamma_{\text{Sig}}.i}$,
otherwise broadcast
$\textrm{V}^{e}_{i}=(i,e,H^{*}(\textrm{M}^{e}),\text{no})_{\Gamma_{\text{Sig}}.i}$.
Metablock Notarization: $\textrm{M}^{e}$ is notarized when at least
$\frac{2n}{3}$ players vote ‘yes’, and no player votes ‘no’. Metablock
Finalization (from Streamlet $\Pi^{0}_{\text{bft}}$): If in any notarized
metachain, there exist three hash-linked metablocks with consecutive epoch
numbers, the prefix of the metachain up to the second of the three metablocks
is considered final. Further, when a metablock is finalized, its parent chain
is also finalized.

####  5.4.1. Correctness

We first show that the best metablock response by rational head players is
$\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$.

Lemma 4 (Rational Leader Metablock). _Assuming that rational players wish to
maximize their utility under $v^{e}_{\mathcal{A}}$, the dominant strategy on
metablock proposal for each rational head player $i^{\prime}\in[m]$ is
$\sigma^{i^{\prime}}_{\tilde{\mathcal{M}}^{e}_{\mathcal{A}}}$, for each epoch
$e$ when $L_{e}=i^{\prime}$._
_Proof._ The payoff for rational leaders as part of $v^{e}_{\mathcal{A}}$ is
on (i) the revenue from the block payload confirmation; and (ii) the
visibility into the list of transactions. For (i), note that the rational
leader may attempt to fork the metachain to orphan some metablocks, if it
results in a higher revenue for it. The rational leader may also consider
announcing two metablocks in quick succession for the same epoch in which it
is a leader if it receives a second payload in the same epoch which has a
higher revenue possible666Consider, for some epoch $e$, $i^{\prime}$ receives
$\textsf{txs}^{e}_{1}$ at $e$ and $\textsf{txs}^{e}_{2}$ at $e+\epsilon$ (for
a small $\epsilon$), with
$\tau_{\mathcal{A}}(\textsf{txs}^{e}_{2})>\tau_{\mathcal{A}}(\textsf{txs}^{e}_{1})$.
$i^{\prime}$ would announce metablocks for both payloads.. For (ii), the
rational leaders’ payoff is maximized when all faulty players learn
$\textsf{txs}^{e},\forall e$. This can only happen when each faulty player
receives the secret key $\Gamma_{\text{vFE}}.\textrm{sk}_{f^{*}}$ for each
epoch in which a rational player is elected leader.
Finally, it is easy to see that $v^{e}_{\mathcal{A}}=0$ if the rational
leader’s block is unnotarized, and $v^{e}_{\mathcal{A}}>0$ if the rational
leader’s block is notarized (even if the payload related revenue is zero, the
payload view payoff is positive). Consequently, both (i) and (ii) are
achievable only when a rational leader’s metablock is notarized, which is only
possible when each honest player $i$ receives
$\Gamma_{\text{vFE}}.\textrm{sk}_{f^{e}_{i}}$.
These arguments imply that the best choice of a metablock from rational
leaders $i^{\prime}\in[m]$ is $\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$, denoted
by the strategy $\sigma^{i^{\prime}}_{\tilde{\mathcal{M}}^{e}_{\mathcal{A}}}$.
$\hfill\square$

We now show that the SightSteeple-RFT protocol is correct.

Theorem 5 (SS-RFT Correctness). _The SightSteeple-RFT protocol
$\mathbf{\Pi}^{ss}_{\text{rft}}$ achieves functional blockchain consensus, in
the presence of a rational-fault adversary $\mathcal{A}$, with
$|\mathcal{A}|<\frac{n}{3}$._
_Proof._ Since the notarization and finalization rules in
$\mathbf{\Pi}^{ss}_{\text{rft}}$ are equivalent to those in
$\Pi^{0}_{\text{bft}}$, the $\mathbf{\Pi}^{ss}_{\text{rft}}$ metachain will be
consistent across all players (Theorem 3 in (Chan and Shi, 2020)). We will now
show that $\mathbf{\Pi}^{ss}_{\text{rft}}$ achieves the three goals of
functional blockchain consensus (Definition 2), considering a consistent
metablock $\textrm{M}^{e}$ from an arbitrary epoch $e$, and remembering the
metablock response from honest leaders is $\mathcal{M}^{e}_{\mathcal{H}}$ and
that from rational leaders is $\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$ (Lemma
4):

(i) Functional Hierarchy Consistency: Since all honest players vote on the
genesis block which contains $([n],\mathcal{C},\mathbb{F},\Psi)$, and vote
‘yes’ on the metablock $\textrm{M}^{e}$ which contains
$(f^{e}_{i})_{i\in[n]}$, it is implied that all honest players agree on
$(\Psi(\kappa_{i})=f^{e}_{i}\in\mathbb{F})_{i\in[n]}$.

(ii) Block Payload View Integrity: Since each honest player voted ‘yes’ on the
metablock (which is one of $\mathcal{M}^{e}_{\mathcal{H}}$ or
$\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$), and no player voted ‘no’, it is
implied that the verification of $f^{e}_{i}$ under $\Gamma_{\text{vFE}}$
succeeded for each honest player $i\in[n]$, and so it is true that each honest
player knows that each honest player $i\in[n]$ agrees on
$f^{e}_{i}(\textsf{txs}^{e})$. Further, since each honest head player voted
‘yes’, it is true that $\textsf{txs}^{e}$ doesn’t contain double spending
transactions.

(iii) Liveness: The $\mathbf{\Pi}^{ss}_{\text{rft}}$ metablock finalization
rule is identical to the $\Pi^{0}_{\text{bft}}$ block finalization rule. Thus,
the liveness of $\mathbf{\Pi}^{ss}_{\text{rft}}$ is implied by Theorem 6 in
(Chan and Shi, 2020) (details in Appendix A.1). $\hfill\square$

#### The $\mathbf{\Pi}^{\text{ss}}_{\text{rft}}$ metachain implies each player
chain

Consider, for any epoch $e$, the metachain $\textsf{mchain}^{e}$ and the most
recent metablock $\textrm{M}^{e}$ in it. Also consider, for each honest player
$i\in[n]$, the sub-metablock $\textrm{M}^{e}_{i}$ of $\textrm{M}^{e}$.
$\textrm{M}^{e}_{i}$ contains:
1\.
$(e,H^{*}(\mathrm{M}^{e^{\prime}}),\Gamma_{\text{vFE}}.\textrm{pp}^{e},\Gamma_{\text{vFE}}.\textrm{Enc}(\textsf{txs}^{e}))_{\Gamma_{\text{Sig}}.L_{e}}$
2\.
$(i,H^{*}(\textsf{chain}_{i}^{e-1}),f^{e}_{i},(\Gamma_{\text{vFE}}.\textrm{sk}_{f^{e}_{i}})_{\Gamma_{\text{E}}.i^{-1}})_{\Gamma_{\text{Sig}}.L_{e}}$
From both these messages, it is easy for player $i$ to imply
$\textsf{chain}^{e}_{i}=(\textsf{chain}^{e-1}_{i},H^{*}(f^{e^{\prime}}_{i}(\textsf{txs}^{e^{\prime}})),f^{e}_{i}(\textsf{txs}^{e}))$,
by recovering the encrypted secret key $\textrm{sk}_{f^{e}_{i}}$ under
$\Gamma_{\text{E}}$, followed by recovering $f^{e}_{i}(\textsf{txs}^{e})$
under $\Gamma_{\text{vFE}}$.

###  5.5. Special Case: Perfect SightSteeple-RFT

We outline a special case where each player, honest or rational-faulty, agrees
on a correct block payload view for each epoch of the SightSteeple metachain.
Given the player network $[n]$, consider the case where, for each credential,
there are at least $a_{0}$ players with that credential, and among those
players, there is at least one honest player, and less than $a_{0}$ rational
players. Now, by using a single $(n,a_{0})$ threshold encryption (Desmedt and
Frankel, 1989) of the secret payload view function key for all players with
the same credential, the rational leaders would be forced to encrypt the
correct view function key in the metablock for all faulty players (if the
rational leader wants its metablock to be notarized by the honest players).
Consequently, perfect SightSteeple-RFT can be achieved, where $\forall
e,\forall i\in[n]$, $i$ learns nothing other than
$f^{e}_{i}(\textsf{txs}^{e})$.
Giving an exact construction and correctness proof for this special case of
SightSteeple-RFT is left as a future exercise.

##  6\. Discussion

###  6.1. Functional Blockchain Consensus for dApps

We discuss possible applications of asymmetric distributed ledgers resulting
from functional blockchain consensus.

_Cryptocurrencies(Bonneau et al., 2015) with sensitive transactions._ We
demonstrate how asymmetric distributed ledgers for cryptocurrencies with
privileged transactions, based on sub-types of functional encryption, can be
constructed, assuming the init-party is a cross-jursidictional network of
federal regulators. The first sub-type of functional encryption we consider is
attribute based encryption (ABE) (Lewko et al., 2010), which allows recovery
of the plaintext if the decryptor satisfies certain attributes. Using ABE,
SightSteeple can be defined to allow players in specific federal jurisdictions
to learn the complete list of transactions. The next sub-type of functional
encryption we consider is predicate encryption (PE) (Boneh et al., 2011),
which allows recovery of the plaintext if some predicate on the plaintext is
true (based on the key held by the decryptor). SightSteeple can be defined
with PE to allow a subset of players to learn the list of transactions if a
specific transactor (say Alice) has a transaction in it. Finally, a functional
encryption scheme with the inner-product functionality (IP) (Abdalla et al.,
2015) can be used to learn the sum of a sub-sequence of the plaintext.
SightSteeple with IP can be used to allow players to learn the sum value of
all crypto-tokens exchanged in the list of transactions.

_Asymmetric Decentralized Finance (DeFi)(Werner et al., 2021; Zetzsche et al.,
2020) applications._ We present some asymmetric financial market solutions
that can result from functional blockchain consensus. First, asymmetric
automated markets may be defined by achieving functional blockchain consensus
on a subset of asset reserves per player (thereby locking in a sub-pool of
assets in the smart contract corresponding to each player). Next, asymmetric
portfolio management and exposure can be achieved through functional
blockchain consensus, to facilitate different DeFi protocols, such as
protocols for loanable funds and automated market makers, for different
subsets of players. Finally, derivative trading under different combinations o
of synthetic assets, futures, perpetual swaps and options, for different
subsets of players, may be achieved through functional blockchain consensus.
The init-party for such applications could be a benevolent dictator (Werner et
al., 2021), that initializes each application appropriately for financial
governance.

_Other dApps(Casino et al., 2019)._ As a final example, functional blockchain
consensus can facilitate the need for asymmetric records for agreement on
classified information in governance (Oliveira et al., 2020; ConsenSys, 2022)
(for instance on citizenship and voting records), healthcare (McGhin et al.,
2019; Hölbl et al., 2018; Builtin, 2022) (on patient healthcare records), and
decentralized IoT network management (Casino et al., 2019) requiring agreement
on sensitive RFID sensor data such as from supply chains, transportation
networks, and inventory management.

###  6.2. Block Payload View Privilege Alteration

It has been shown in Section 5.5, that perfect rational-fault tolerance in
SightSteeple, where, $\forall e$, each player $i\in[n]$ provably learns
$f^{e}_{i}(\textsf{txs}^{e})$, with
$(\Psi(\kappa_{i})=f^{e}_{i}\in\mathbb{F})_{i\in[n]}$, is only achievable as a
special case. In general, the rational players can violate their privileges to
learn the entire payload, whenever a rational head player is elected as the
metablock proposer. We revisit the privilege alteration properties of
SightSteeple, seen so far.

_Inherent Collusion to Supersede Privilege._ The adversary in SightSteeple-RFT
implicitly learns
$\sup_{\preceq}\\{f^{e}_{i^{\prime}}(\textsf{txs}^{e})\\}_{i^{\prime}\in\mathcal{A}}$,
for each epoch $e$, as it controls all players in $\mathcal{A}$.

_Privilege alteration would be ineffective in escalated information going on-
chain for honest players._ It has been established that, given a rational-
fault adversary, the metablock response by honest leaders in the SightSteeple
protocol is $\mathcal{M}^{e}_{\mathcal{H}}$, and the best metablock response
by rational leaders is $\tilde{\mathcal{M}}^{e}_{\mathcal{A}}$ (Lemma 4). In
both instances, it is true that the secret functional encryption key supplied
for each honest $i\in[n]$ is no different from
$\textrm{sk}_{\Psi(\kappa_{i})}$. This implies that although the rational
players might learn the entire list of transactions, the correctness is
preserved for all honest players.

_Off-Chain Privilege Preservation._ In future, in order to ensure $\forall e$,
each player $i\in[n]$ provably learns $f^{e}_{i}(\textsf{txs}^{e})$, with
$(\Psi(\kappa_{i})=f^{e}_{i}\in\mathbb{F})_{i\in[n]}$, metablock proposal may
be made an off-chain activity. Options to outsource metablock creation include
payload view function key generation through decentralized blockchain-based
multi-party computation (Zhong et al., 2019), or through dynamic decentralized
functional encryption (Chotard et al., 2020), or through an alternate, oracle
blockchain system (Cui et al., 2020b).

###  6.3. SightSteeple Protocol Optimization

The present version of SightSteeple has some overheads in terms of space
complexity of the proposed metablock, and overall communication complexity per
epoch of metablock proposal. Both SightSteeple-CFT and SightSteeple-RFT have
metablock size $|\textsf{M}^{e}|\in\Theta(n)$. Further, since the base
protocol Streamlet echoes each message (Cohen and Malkhi, 2022), the current
communication complexity $\forall e$ is
$n^{2}(|\textsf{M}^{e}|+n|\textsf{V}^{e}|)=\Theta(n^{3})$.
In future, we would like to reduce the metablock size, and supplant the base
protocol from Streamlet to HotStuff (Yin et al., 2019), to reduce the
communication complexity, and provide an API for implementation (Cohen and
Malkhi, 2022; Viswanath, 2022).

###  6.4. Function and Block Payload Privacy

We give a brief discussion on whether any information about the payload,
beyond what is presented in the metablock, is leaked, under the associated
functional encryption scheme. The following arguments are based on message
privacy (from Appendix A.2), which translates to payload privacy in
SightSteeple, remembering that payloads are the functionally encrypted
messages in the metablocks.

_Under crash-fault tolerance._ $\Gamma_{\text{aFE}}$ achieves full message
privacy (Brakerski and Segev, 2018), which implies that SightSteeple-CFT
achieves full payload privacy for each function in $\mathbb{F}$, even though
any of the players might not be intending to infer extra information from what
is conveyed for them individually in the metachain.

_Under rational-fault tolerance._ Function Privacy (Brakerski and Segev, 2018)
is not achieved in the present version of SightSteeple, as the view functions
are public in the metablock, in order to ensure the functional hierarchy
consistency. Block payload security requirements are implied by the re-
instantiation of the verifiable functional encryption scheme parameters per
epoch, in SightSteeple-RFT. In the SightSteeple-RFT protocol, the adversary
sees $1$ payload and less than $\frac{n}{3}$ functions applied on the payload,
in each epoch (which has a separate instantiation of the verifiable functional
encryption scheme parameters). Thus SightSteeple-RFT requires at least
$1$-selective-message payload privacy and at least $\frac{n}{3}$-selective-
function payload privacy (Brakerski and Segev, 2018) (security notions
outlined in A.2) under $\Gamma_{\text{vFE}}$, proving which is beyond the
scope of this contribution.

##  7\. Future Directions

We have initiated a new line of enquiry into functional blockchain consensus,
and proposed a first functional blockchain consensus protocol SightSteeple
providing an asymmetric visibility into the list of transactions. To conclude,
we outline some problems emerging from this contribution, that can be
addressed in future.

_Off-chain metablock creation for privilege preservation._ Presently, the
block payload view decryption is part of the consensus protocol, as part of
the validation of the metablock. In future, SightSteeple can be amended to
eliminate privilege escalation by adversarial metablock proposers, through
outsourced (if needed verifiable) decryption under a functional encryption
scheme, using standard blockchains (Cui et al., 2020b).

_In hidden credentials’ networks, understanding the tradeoff between
expressiveness of function families $\mathbb{F}$ versus function-privacy under
various FE schemes._ SightSteeple is constructed to reveal the credentials and
view functions for each player. In future, for privacy, if the credentials and
view functions per player need not be revealed while achieving functional
hierarchy consistency, then function-private functional encryption schemes
(Brakerski and Segev, 2018) may be employed to achieve functional blockchain
consensus. Given a adversary $\mathcal{A}\subseteq[n]$, collusion can be
prevented using function-private functional encryption, to prevent
$\mathcal{A}$ from learning more than
$\\{f_{i^{\prime}}(\textsf{txs})\\}_{i^{\prime}\in\mathcal{A}}$, in terms of
payload information and view functions, for each payload txs going on-chain.
However, in this case, the permissible set of view functions $\mathbb{F}$
supported by the functional encryption scheme is an open question, which may
be addressed in future.

_Functional blockchain consensus in the BAR and ByRa models(McMenamin et al.,
2021)._ SightSteeple has been constructed to be resilient to crash-faults and
rational-faults. It has been shown that SightSteeple cannot be appropriately
modified to achieve Byzantine-fault tolerance (Section 5.1). In future,
alternate protocols for functional blockchain consensus may be proposed for
tolerance to a combination of Byzantine and rational players in the presence
of altruistic/honest players (the BAR model), or functional blockchain
consensus may be attained in the absence of honest players altogether
(identical to the ByRa model of the Tenderstake (McMenamin et al., 2021)
protocol).

_Towards asymmetric smart contracts._ Traditionally, for each participant in
the distributed system, the execution logic of the smart contract is
predicated on $\textsf{chain}^{*}$. Given the hierarchical player blockchains
resulting from SightSteeple, future _functional_ smart contracts in credential
driven distributed systems, may base their execution logic on
$\textsf{chain}^{e}_{i}$ for player $i$ (or any process privy to player $i$’s
blockchain), or might even base their execution logic on
$\inf_{\preceq}\\{\textsf{chain}^{e}_{i}\\}_{i\in[n]}$ for each player777We
use the $\inf_{\preceq}$ notation on player blockchains to give the same
implication as the $\inf_{\preceq}$ notation on payload view in Section 2.4..

_Proposing declassification blockchain consensus._ In the instance that a
peer-to-peer network requires agreement on sensitive information that cannot
be revealed in completion immediately, but can safely be divulged in the
future, a declassification blockchain protocol can be defined to reach the
said goal. To that end, we propose the following definition of
declassification consensus, which may be realized using a SightSteeple-like
protocol in the future.
Proposed Definition (Declassification Consensus). _Given a declassification
window $H$, $\forall h,\exists f\in\mathbb{F},f\neq f^{*}$, such that if the
honest players in $[n]$ finalize $f(\textsf{txs}^{h})$ at height $h$, then
they also finalize $\textsf{txs}^{h}$ at height $h+H$._

We so believe that through this contribution, and through the possible future
directions as stated above, SightSteeple would be a stepping stone towards
defining new consensus paradigms and protocols for an asymmetric agreement on
privileged information.

## References

  * (1)
  * Abdalla et al. (2015) Michel Abdalla, Florian Bourse, Angelo De Caro, and David Pointcheval. 2015.  Simple functional encryption schemes for inner products. In _IACR International Workshop on Public Key Cryptography_. Springer, 733–751.
  * Ahuja et al. (2021) Poonam Ahuja, Deepak Ahuja, and Aditya Ahuja. WIPO International Publication No. WO 2021/205241 A1, 14 Oct. 2021.  System and method for establishing a trusted functional blockchain consensus.  https://patents.google.com/patent/WO2021205241A1/en.
  * Badrinarayanan et al. (2016) Saikrishna Badrinarayanan, Vipul Goyal, Aayush Jain, and Amit Sahai. 2016.  Verifiable functional encryption. In _International Conference on the Theory and Application of Cryptology and Information Security_. Springer, 557–587.
  * Banerjee and Chandrakasan (2021) Utsav Banerjee and Anantha P Chandrakasan. 2021.  A Low-Power Elliptic Curve Pairing Crypto-Processor for Secure Embedded Blockchain and Functional Encryption. In _2021 IEEE Custom Integrated Circuits Conference (CICC)_. IEEE, 1–2.
  * Bano et al. (2019) Shehar Bano, Alberto Sonnino, Mustafa Al-Bassam, Sarah Azouvi, Patrick McCorry, Sarah Meiklejohn, and George Danezis. 2019\.  SoK: Consensus in the age of blockchains. In _Proceedings of the 1st ACM Conference on Advances in Financial Technologies_. 183–198.
  * Boneh et al. (2011) Dan Boneh, Amit Sahai, and Brent Waters. 2011.  Functional encryption: Definitions and challenges. In _Theory of Cryptography Conference_. Springer, 253–273.
  * Bonneau et al. (2015) Joseph Bonneau, Andrew Miller, Jeremy Clark, Arvind Narayanan, Joshua A Kroll, and Edward W Felten. 2015\.  Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In _2015 IEEE symposium on security and privacy_. IEEE, 104–121.
  * Brakerski and Segev (2018) Zvika Brakerski and Gil Segev. 2018.  Function-private functional encryption in the private-key setting.  _Journal of Cryptology_ 31, 1 (2018), 202–225.
  * Builtin (2022) Builtin. (Online; Accessed 21-Feb-2022).  _Blockchain in Healthcare: 15 Examples_.  https://builtin.com/blockchain/blockchain-healthcare-applications-companies
  * Cachin (2021) Christian Cachin. 2021\.  Asymmetric distributed trust. In _International Conference on Distributed Computing and Networking 2021_. 3–3.
  * Cachin and Zanolini (2021) Christian Cachin and Luca Zanolini. 2021.  Asymmetric Asynchronous Byzantine Consensus.  In _Data Privacy Management, Cryptocurrencies and Blockchain Technology_. Springer, 192–207.
  * Casino et al. (2019) Fran Casino, Thomas K Dasaklis, and Constantinos Patsakis. 2019\.  A systematic literature review of blockchain-based applications: Current status, classification and open issues.  _Telematics and informatics_ 36 (2019), 55–81.
  * Chan and Shi (2020) Benjamin Y Chan and Elaine Shi. 2020.  Streamlet: Textbook streamlined blockchains. In _Proceedings of the 2nd ACM Conference on Advances in Financial Technologies_. 1–11.
  * Chotard et al. (2020) Jérémy Chotard, Edouard Dufour-Sans, Romain Gay, Duong Hieu Phan, and David Pointcheval. 2020.  Dynamic decentralized functional encryption. In _Annual International Cryptology Conference_. Springer, 747–775.
  * Cohen and Malkhi (2022) Shir Cohen and Dahlia Malkhi. (Online; Accessed 21-Feb-2022).  _What They Did not Teach you in Streamlet_.  https://dahliamalkhi.github.io/posts/2020/12/what-they-didnt-teach-you-in-streamlet/
  * ConsenSys (2022) ConsenSys. (Online; Accessed 21-Feb-2022).  _Blockchain in Government and Public Sector_.  https://consensys.net/blockchain-use-cases/government-and-the-public-sector/
  * Cui et al. (2020b) Hui Cui, Zhiguo Wan, Xinlei Wei, Surya Nepal, and Xun Yi. 2020b.  Pay as you decrypt: Decryption outsourcing for functional encryption using blockchain.  _IEEE Transactions on Information Forensics and Security_ 15 (2020), 3227–3238.
  * Cui et al. (2020a) Zhihua Cui, XUE Fei, Shiqiang Zhang, Xingjuan Cai, Yang Cao, Wensheng Zhang, and Jinjun Chen. 2020a.  A hybrid blockchain-based identity authentication scheme for multi-WSN.  _IEEE Transactions on Services Computing_ 13, 2 (2020), 241–251.
  * Denning (1976) Dorothy E Denning. 1976\.  A lattice model of secure information flow.  _Commun. ACM_ 19, 5 (1976), 236–243.
  * Desmedt and Frankel (1989) Yvo Desmedt and Yair Frankel. 1989.  Threshold cryptosystems. In _Conference on the Theory and Application of Cryptology_. Springer, 307–315.
  * Dolev and Strong (1983) Danny Dolev and H. Raymond Strong. 1983.  Authenticated algorithms for Byzantine agreement.  _SIAM J. Comput._ 12, 4 (1983), 656–666.
  * Dwork et al. (1988) Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. 1988\.  Consensus in the presence of partial synchrony.  _Journal of the ACM (JACM)_ 35, 2 (1988), 288–323.
  * Garg et al. (2016) Sanjam Garg, Craig Gentry, Shai Halevi, Mariana Raykova, Amit Sahai, and Brent Waters. 2016\.  Candidate indistinguishability obfuscation and functional encryption for all circuits.  _SIAM J. Comput._ 45, 3 (2016), 882–929.
  * Garg et al. (2014) Sanjam Garg, Craig Gentry, Shai Halevi, and Mark Zhandry. 2014.  Fully Secure Functional Encryption without Obfuscation.  _IACR Cryptol. ePrint Arch._ 2014 (2014), 666.
  * Gorbunov et al. (2012) Sergey Gorbunov, Vinod Vaikuntanathan, and Hoeteck Wee. 2012\.  Functional encryption with bounded collusions via multi-party computation. In _Annual Cryptology Conference_. Springer, 162–179.
  * Hölbl et al. (2018) Marko Hölbl, Marko Kompara, Aida Kamišalić, and Lili Nemec Zlatolas. 2018.  A systematic review of the use of blockchain in healthcare.  _Symmetry_ 10, 10 (2018), 470.
  * Lewko et al. (2010) Allison Lewko, Tatsuaki Okamoto, Amit Sahai, Katsuyuki Takashima, and Brent Waters. 2010\.  Fully secure functional encryption: Attribute-based encryption and (hierarchical) inner product encryption. In _Annual International Conference on the Theory and Applications of Cryptographic Techniques_. Springer, 62–91.
  * McGhin et al. (2019) Thomas McGhin, Kim-Kwang Raymond Choo, Charles Zhechao Liu, and Debiao He. 2019.  Blockchain in healthcare applications: Research challenges and opportunities.  _Journal of Network and Computer Applications_ 135 (2019), 62–75.
  * McMenamin et al. (2021) Conor McMenamin, Vanesa Daza, and Matteo Pontecorvi. 2021\.  Achieving State Machine Replication without Honest Players. In _Proceedings of the 3rd ACM Conference on Advances in Financial Technologies_.
  * Mirkin et al. (2020) Michael Mirkin, Yan Ji, Jonathan Pang, Ariah Klages-Mundt, Ittay Eyal, and Ari Juels. 2020\.  BDoS: Blockchain denial-of-service. In _Proceedings of the 2020 ACM SIGSAC conference on Computer and Communications Security_. 601–619.
  * Oliveira et al. (2020) Thays A Oliveira, Miquel Oliver, and Helena Ramalhinho. 2020\.  Challenges for connecting citizens and smart cities: ICT, e-governance and blockchain.  _Sustainability_ 12, 7 (2020), 2926.
  * Shi (2020) Elaine Shi. 2020\.  Foundations of Distributed Consensus and Blockchains.  https://www.distributedconsensus.net/.  Book (Publicly Available).
  * Sliwinski and Wattenhofer (2019) Jakub Sliwinski and Roger Wattenhofer. 2019.  Abc: Asynchronous blockchain without consensus.  _arXiv preprint arXiv:1909.10926_ (2019).
  * Son et al. (2020) Ye-Byoul Son, Jong-Hyuk Im, Hee-Yong Kwon, Seong-Yun Jeon, and Mun-Kyu Lee. 2020.  Privacy-preserving peer-to-peer energy trading in blockchain-enabled smart grids using functional encryption.  _Energies_ 13, 6 (2020), 1321.
  * Viswanath (2022) Pramod Viswanath. (Online; Accessed 21-Feb-2022).  _Blockchain protocols with finality: Streamlet and HotStuff_.  https://courses.grainger.illinois.edu/ece598pv/sp2021/lectureslides2021/ECE_598_PV_course_notes14.pdf
  * Werner et al. (2021) Sam M Werner, Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Dominik Harz, and William J Knottenbelt. 2021.  Sok: Decentralized finance (defi).  _arXiv preprint arXiv:2101.08778_ (2021).
  * Xiao et al. (2020) Yang Xiao, Ning Zhang, Wenjing Lou, and Y Thomas Hou. 2020\.  A survey of distributed consensus protocols for blockchain networks.  _IEEE Communications Surveys and Tutorials_ 22, 2 (2020), 1432–1465.
  * Yin et al. (2019) Maofan Yin, Dahlia Malkhi, Michael K Reiter, Guy Golan Gueta, and Ittai Abraham. 2019\.  HotStuff: BFT consensus with linearity and responsiveness. In _Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing_. 347–356.
  * Yurchenko et al. (2020) Artem Yurchenko, Mahbuba Moni, Daniel Peters, Jan Nordholz, and Florian Thiel. 2020.  Security for Distributed Smart Meter: Blockchain-based Approach, Ensuring Privacy by Functional Encryption.. In _CLOSER_. 292–301.
  * Zetzsche et al. (2020) Dirk A Zetzsche, Douglas W Arner, and Ross P Buckley. 2020\.  Decentralized finance.  _Journal of Financial Regulation_ 6, 2 (2020), 172–203.
  * Zhong et al. (2019) Hanrui Zhong, Yingpeng Sang, Yongchun Zhang, and Zhicheng Xi. 2019.  Secure multi-party computation on blockchain: An overview. In _International Symposium on Parallel Architectures, Algorithms and Programming_. Springer, 452–460.
  * Zhu et al. (2019) Saide Zhu, Zhipeng Cai, Huafu Hu, Yingshu Li, and Wei Li. 2019.  zkCrowd: a hybrid blockchain-based crowdsourcing platform.  _IEEE Transactions on Industrial Informatics_ 16, 6 (2019), 4196–4205.

##  Appendix A Background

###  A.1. Streamlet: Main Results

Streamlet (Chan and Shi, 2020) is a simple blockchain protocol where consensus
evolves in four streamlined stages to achieve consistency and liveness: (i) a
block is proposed by a random leader on the set of all players; (ii) the first
correct block seen by honest players is voted on; (iii) a block is considered
‘notarized’ once a threshold of players vote on it; and lastly (iv) notarized
block(s) are finalized under different finalization rules depending on the
network model and the power of the adversary.

For our contribution, we would only consider Streamlet over a partially
synchronous network (Dwork et al., 1988), with a crash-fault adversary of size
$<\frac{n}{2}$ in the network (denoted by $\Pi^{0}_{\text{cft}}$), or a
Byzantine-fault adversary of size $<\frac{n}{3}$ in the network (denoted by
$\Pi^{0}_{\text{bft}}$).

For both $\Pi^{0}_{\text{cft}}$ and $\Pi^{0}_{\text{bft}}$, the block
finalization rule states that if a player sees three adjacent notarized
blocks, with consecutive epoch numbers, then the second of the three blocks,
along with its parent chain, is finalized. The same finalization rule is
applied to $\mathbf{\Pi}^{ss}_{\text{cft}}$ and
$\mathbf{\Pi}^{ss}_{\text{rft}}$.

Further, for both $\Pi^{0}_{\text{cft}}$ and $\Pi^{0}_{\text{bft}}$, the proof
of consistency is similar. First, it is shown that for any epoch, for any
honest player’s blockchain snapshot, at most one block is notarized. Next, it
is shown that given a block branch with three adjacent notarized blocks with
three consecutive epoch numbers, there cannot exist a notarized block at
length 2 in any competing branch. These basic arguments lead to Theorems 3 and
12 on consistency for Byzantine-fault tolerant Streamlet and crash-fault
tolerant Streamlet respectively, in (Chan and Shi, 2020).

The liveness theorems of $\Pi^{0}_{\text{cft}}$ and $\Pi^{0}_{\text{bft}}$ are
also identical, and are given next.
Streamlet Liveness (Theorems 6 and 13 in (Chan and Shi, 2020)). _After GST,
suppose that there are 5 consecutive epochs $e,e+1,...,e+4$, all with honest
leaders, then, by the beginning of epoch $e+5$, every honest node must have
observed a new final block that was not final at the beginning of epoch $e$.
Moreover, this new block was proposed by an honest leader._

###  A.2. Fundamentals of Functional Encryption

Functional encryption differs from traditional encryption by allowing the
decryptor to recover _any function of_ the message from the encryption of the
message, instead of allowing the decryptor to recover the message from its
encryption. We outline the basics of function encryption and its variants
relevant to our contribution. We then highlight various notions of security
that different functional encryption schemes may achieve.

####  A.2.1. Basic Functional Encryption

A functional encryption scheme (Boneh et al., 2011), given a set of functions
$\mathbf{F}$ over some message space $M$, is a tuple of four probabilistic
polynomial time algorithms
$(\textsf{Setup},\textsf{KeyGen},\textsf{Enc},\textsf{Dec})$ where, $\forall
m\in M$:
$(pp,msk)\leftarrow\textsf{Setup}(1^{\lambda})$
$sk_{f}\leftarrow\textsf{KeyGen}(msk,f)$ for some $f\in\mathbf{F}$
$ctx\leftarrow\textsf{Enc}_{pp}(m)$
$f(m)\leftarrow\textsf{Dec}(sk_{f},ctx)$
where the decryption succeeds with at least an overwhelming probability in the
security parameter $\lambda$. The parameters $pp$ are public, whereas the key
$msk$ to generate the function secret key(s) is private.

####  A.2.2. Functional Encryption for all Circuits

A functional encryption scheme for all circuits has the same specification as
a standard functional encryption scheme, except that it supports functionality
(decryption) $\mathbf{F}$ for all efficiently computable functions on the
message space. Examples of such schemes are (Garg et al., 2016) and (Garg et
al., 2014). The scheme (Garg et al., 2016) achieves selective-message message
privacy, and the scheme (Garg et al., 2014) achieves full message privacy
(both security notions defined below). We denote a functional encryption
scheme for all circuits by $\Gamma_{\text{aFE}}$.

####  A.2.3. Verifiable Functional Encryption

A verifiable functional encryption scheme (Badrinarayanan et al., 2016)
supports, in addition to the base algorithms
$(\textsf{Setup},\textsf{KeyGen},\textsf{Enc},\textsf{Dec})$, two additional
algorithms
$(\textsf{VerCT},\textsf{VerKey})$, such that
$0/1\leftarrow\textsf{VerCT}(pp,ctx)$ (output true if the ciphertext was
generated using the correct public parameters)
$0/1\leftarrow\textsf{VerKey}(pp,f,sk_{f})$ (output true if the secret
function key indeed corresponds to the function $f$)
Verifiable functional encryption works by modifying an existing functional
encryption scheme. Reasonable candidates for the underlying functional
encryption scheme are (Garg et al., 2016) (which achieves selective-message
message privacy) and (Gorbunov et al., 2012) (which achieves selective-
function message privacy). We denote a verifiable functional encryption scheme
by $\Gamma_{\text{vFE}}$.

####  A.2.4. Security of Functional Encryption Schemes

We briefly discuss different notions of message privacy security of functional
encryption schemes (Brakerski and Segev, 2018). This notion of security
translates to the security properties of the payload under SightSteeple. We
will denote the adversary by $\mathbb{A}$.

_Valid message privacy adversary._ $\mathbb{A}$ is a valid (polynomial time)
message privacy adversary if for all functions $\\{f_{i}\\}_{i\leq T}$ for
which it queries the KeyGen oracle of the scheme for secret keys, and for all
messages $\\{m_{j}\\}_{j\leq T^{\prime}}$ it receives encryptions of under the
scheme, it is true that $f_{i_{1}}(m_{j_{1}})=f_{i_{2}}(m_{j_{2}})$, $\forall
i_{1},i_{2}\in[T],j_{1},j_{2}\in[T^{\prime}]$. We will assume that for each of
the message privacy models below, $\mathbb{A}$ is a valid message privacy
adversary.

_Full message privacy._ Full message privacy dictates that, given an adversary
$\mathbb{A}$, that can request for any number of function keys from the key
generation oracle of the scheme, under valid message privacy, the encryptions
of any two messages received from the encryption oracle of the scheme, for
$\mathbb{A}$, are computationally indistinguishable.

_Selective-message message privacy._ Given any two vectors of messages, where
each message vector has length $k$, and allowing $\mathbb{A}$ to request any
number of function keys from the key generation oracle of the scheme, under
valid message privacy, $k$-selective-message message privacy dictates that the
encryptions of the two message vectors received from the encryption oracle of
the scheme, are computationally indistinguishable for $\mathbb{A}$. The scheme
achieves selective-message message privacy, if it is $k$-selective-message
message private for all polynomials $k$ in the security parameter.

_Selective-function message privacy._ Given secret keys of $k$ arbitrary
functions received from the key generation oracle of the scheme by the
adversary $\mathbb{A}$, $k$-selective-function message privacy dictates that
the encryptions of any two messages received from the encryption oracle of the
scheme, are computationally indistinguishable for $\mathbb{A}$. The scheme
achieves selective-function message privacy, if it is $k$-selective-function
message private for all polynomials $k$ in the security parameter.