├── .gitignore ├── LICENSE ├── README.md ├── assets ├── logo.png ├── logo.svg ├── settlementflow.pdf ├── strategies.pdf ├── txo.pdf ├── txtree.pdf └── upsilon.pdf ├── prometheus.pdf ├── prometheus.tex ├── references.bib └── tikz-uml.sty /.gitignore: -------------------------------------------------------------------------------- 1 | ## Core latex/pdflatex auxiliary files: 2 | *.aux 3 | *.lof 4 | *.log 5 | *.lot 6 | *.fls 7 | *.out 8 | *.toc 9 | *.fmt 10 | *.fot 11 | *.cb 12 | *.cb2 13 | .*.lb 14 | 15 | ## Intermediate documents: 16 | *.dvi 17 | *.xdv 18 | *-converted-to.* 19 | # these rules might exclude image files for figures etc. 20 | # *.ps 21 | # *.eps 22 | # *.pdf 23 | 24 | ## Generated if empty string is given at "Please type another file name for output:" 25 | .pdf 26 | 27 | ## Bibliography auxiliary files (bibtex/biblatex/biber): 28 | *.bbl 29 | *.bcf 30 | *.blg 31 | *-blx.aux 32 | *-blx.bib 33 | *.run.xml 34 | 35 | ## Build tool auxiliary files: 36 | *.fdb_latexmk 37 | *.synctex 38 | *.synctex(busy) 39 | *.synctex.gz 40 | *.synctex.gz(busy) 41 | *.pdfsync 42 | 43 | ## Auxiliary and intermediate files from other packages: 44 | # algorithms 45 | *.alg 46 | *.loa 47 | 48 | # achemso 49 | acs-*.bib 50 | 51 | # amsthm 52 | *.thm 53 | 54 | # beamer 55 | *.nav 56 | *.pre 57 | *.snm 58 | *.vrb 59 | 60 | # changes 61 | *.soc 62 | 63 | # cprotect 64 | *.cpt 65 | 66 | # elsarticle (documentclass of Elsevier journals) 67 | *.spl 68 | 69 | # endnotes 70 | *.ent 71 | 72 | # fixme 73 | *.lox 74 | 75 | # feynmf/feynmp 76 | *.mf 77 | *.mp 78 | *.t[1-9] 79 | *.t[1-9][0-9] 80 | *.tfm 81 | 82 | #(r)(e)ledmac/(r)(e)ledpar 83 | *.end 84 | *.?end 85 | *.[1-9] 86 | *.[1-9][0-9] 87 | *.[1-9][0-9][0-9] 88 | *.[1-9]R 89 | *.[1-9][0-9]R 90 | *.[1-9][0-9][0-9]R 91 | *.eledsec[1-9] 92 | *.eledsec[1-9]R 93 | *.eledsec[1-9][0-9] 94 | *.eledsec[1-9][0-9]R 95 | *.eledsec[1-9][0-9][0-9] 96 | *.eledsec[1-9][0-9][0-9]R 97 | 98 | # glossaries 99 | *.acn 100 | *.acr 101 | *.glg 102 | *.glo 103 | *.gls 104 | *.glsdefs 105 | 106 | # gnuplottex 107 | *-gnuplottex-* 108 | 109 | # gregoriotex 110 | *.gaux 111 | *.gtex 112 | 113 | # htlatex 114 | *.4ct 115 | *.4tc 116 | *.idv 117 | *.lg 118 | *.trc 119 | *.xref 120 | 121 | # hyperref 122 | *.brf 123 | 124 | # knitr 125 | *-concordance.tex 126 | # TODO Comment the next line if you want to keep your tikz graphics files 127 | *.tikz 128 | *-tikzDictionary 129 | 130 | # listings 131 | *.lol 132 | 133 | # makeidx 134 | *.idx 135 | *.ilg 136 | *.ind 137 | *.ist 138 | 139 | # minitoc 140 | *.maf 141 | *.mlf 142 | *.mlt 143 | *.mtc[0-9]* 144 | *.slf[0-9]* 145 | *.slt[0-9]* 146 | *.stc[0-9]* 147 | 148 | # minted 149 | _minted* 150 | *.pyg 151 | 152 | # morewrites 153 | *.mw 154 | 155 | # nomencl 156 | *.nlg 157 | *.nlo 158 | *.nls 159 | 160 | # pax 161 | *.pax 162 | 163 | # pdfpcnotes 164 | *.pdfpc 165 | 166 | # sagetex 167 | *.sagetex.sage 168 | *.sagetex.py 169 | *.sagetex.scmd 170 | 171 | # scrwfile 172 | *.wrt 173 | 174 | # sympy 175 | *.sout 176 | *.sympy 177 | sympy-plots-for-*.tex/ 178 | 179 | # pdfcomment 180 | *.upa 181 | *.upb 182 | 183 | # pythontex 184 | *.pytxcode 185 | pythontex-files-*/ 186 | 187 | # thmtools 188 | *.loe 189 | 190 | # TikZ & PGF 191 | *.dpth 192 | *.md5 193 | *.auxlock 194 | 195 | # todonotes 196 | *.tdo 197 | 198 | # easy-todo 199 | *.lod 200 | 201 | # xmpincl 202 | *.xmpi 203 | 204 | # xindy 205 | *.xdy 206 | 207 | # xypic precompiled matrices 208 | *.xyc 209 | 210 | # endfloat 211 | *.ttt 212 | *.fff 213 | 214 | # Latexian 215 | TSWLatexianTemp* 216 | 217 | ## Editors: 218 | # WinEdt 219 | *.bak 220 | *.sav 221 | 222 | # Texpad 223 | .texpadtmp 224 | 225 | # Kile 226 | *.backup 227 | 228 | # KBibTeX 229 | *~[0-9]* 230 | 231 | # auto folder when using emacs and auctex 232 | ./auto/* 233 | *.el 234 | 235 | # expex forward references with \gathertags 236 | *-tags.tex 237 | 238 | # standalone packages 239 | *.sta 240 | 241 | # generated if using elsarticle.cls 242 | *.spl 243 | .idea 244 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 Dr. Maxim Orlovsky 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Prometheus 2 | === 3 | 4 | **_Scalable High-load Computing & Machine Learning on top of Bitcoin_** 5 | 6 | Maxim Orlovsky1, 2, Sabina Sachtachtinskagia1, 3 7 | 1Pandora Core AG, Switzerland; 8 | 2BICA Labs, Switzerland; 9 | 3Athens University of Economics and Business, Greece 10 | 11 | Censorship resistant decentralised computing is a new topic in distributed systems theory. With the recent rise in popularity of Bitcoin as a censorship-resistant financial and transactional system a new technological field of blockchain and its applications appeared. This work addresses the problem of computational integrity proofs (correctness of the actual computations) made by some non-trusted (anonymous) third party without repeating the whole volume of the actual computing. The issue is usually addressed by use of probabilistically checkable proofs (PCP), however, such simple approach leave untouched the question of coupling the payments for the consumed computational resources with the actual proof. The purpose of our protocol is to scale distributed calculations by obtaining results of nearly perfect (measurable) quality, without the need to repeat calculations or check the computational integrity proofs by the client. This is achieved by providing meritocratic economic incentives to all participating economic agents, so that their interests are aligned with the network's success. As a result, the need for repeat calculations diminishes, and costs of calculations become lower and competitive. Ability to run PCP schemes without trusted checking party provides a way to codify the actual protocol in terms of smart contracts, so it can be used in a very compact form with existing economic blockchain layer. Our approach to protocol design aims at the smallest possible size of the shared system state so it can be implemented with any non-Turing complete smart contract system with storing nothing else then the account balances for the involved parties. For example, the protocol can be implemented with the existing Bitcoin script functionality with only two on-chain transactions per whole protocol computing cycle. In such system the PCP proofs are run the second layer on top of actual Bitcoin blockchain, reducing the footprint, price and increasing scalability for the real-world business cases for the computing. 12 | 13 | [Check the full PDF version of the paper](./prometheus.pdf) 14 | 15 | ![Prometheus Logo](assets/logo.png) 16 | -------------------------------------------------------------------------------- /assets/logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Prometheus-WG/prometheus-spec/8f15d433274a8e894d501ce4bd11d54c1f3ed25e/assets/logo.png -------------------------------------------------------------------------------- /assets/logo.svg: -------------------------------------------------------------------------------- 1 | Pandora Prometheus -------------------------------------------------------------------------------- /assets/settlementflow.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Prometheus-WG/prometheus-spec/8f15d433274a8e894d501ce4bd11d54c1f3ed25e/assets/settlementflow.pdf -------------------------------------------------------------------------------- /assets/strategies.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Prometheus-WG/prometheus-spec/8f15d433274a8e894d501ce4bd11d54c1f3ed25e/assets/strategies.pdf -------------------------------------------------------------------------------- /assets/txo.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Prometheus-WG/prometheus-spec/8f15d433274a8e894d501ce4bd11d54c1f3ed25e/assets/txo.pdf -------------------------------------------------------------------------------- /assets/txtree.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Prometheus-WG/prometheus-spec/8f15d433274a8e894d501ce4bd11d54c1f3ed25e/assets/txtree.pdf -------------------------------------------------------------------------------- /assets/upsilon.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Prometheus-WG/prometheus-spec/8f15d433274a8e894d501ce4bd11d54c1f3ed25e/assets/upsilon.pdf -------------------------------------------------------------------------------- /prometheus.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Prometheus-WG/prometheus-spec/8f15d433274a8e894d501ce4bd11d54c1f3ed25e/prometheus.pdf -------------------------------------------------------------------------------- /prometheus.tex: -------------------------------------------------------------------------------- 1 | \documentclass[a4paper]{article} 2 | 3 | \usepackage[utf8]{inputenc} 4 | \usepackage[english]{babel} 5 | \usepackage{authblk} 6 | \usepackage{adjustbox} 7 | \usepackage{enumitem} 8 | \usepackage{caption} 9 | \usepackage{xfrac} 10 | \usepackage[pdf]{graphviz} 11 | \usepackage{pgf-umlsd} 12 | \usepackage{array} 13 | \usepackage{makecell} 14 | \usepackage{booktabs} 15 | \usepackage{xcolor} 16 | \usepackage{amsmath} 17 | \usepackage{amssymb} 18 | \usepackage{mathtools} 19 | \usepackage{listings} 20 | \usepackage{verbatim} 21 | \usepackage{indentfirst} 22 | \usepackage[T1]{fontenc} 23 | \usepackage[colorlinks=true, allcolors=blue]{hyperref} 24 | %\usepackage[a4paper,top=3cm,bottom=2cm,left=3cm,right=3cm,marginparwidth=1.75cm]{geometry} 25 | 26 | \babelhyphenation[english]{every-where} 27 | \usetikzlibrary{shapes,arrows} 28 | 29 | \newcolumntype{M}[1]{>{\raggedright\arraybackslash}m{#1}} 30 | 31 | \lstdefinestyle{mystyle}{ 32 | backgroundcolor=\color{lightgray}, 33 | commentstyle=\color{codegreen}, 34 | keywordstyle=\color{magenta}, 35 | numberstyle=\tiny\color{lightgray}, 36 | stringstyle=\color{codepurple}, 37 | basicstyle=\footnotesize, 38 | breakatwhitespace=false, 39 | breaklines=true, 40 | captionpos=b, 41 | keepspaces=true, 42 | numbers=left, 43 | numbersep=5pt, 44 | showspaces=false, 45 | showstringspaces=false, 46 | showtabs=false, 47 | tabsize=2 48 | } 49 | \lstset{style=mystyle} 50 | 51 | \providecommand{\tightlist}{% 52 | \setlength{\itemsep}{0pt}% 53 | \setlength{\parskip}{0pt}% 54 | \setlength{\topsep}{0pt}} 55 | 56 | \title{\textsc{Prometheus}:\\Scalable High-load Computing \& Machine Learning on top of Bitcoin} 57 | \author[1,2]{Maxim Orlovsky\thanks{orlovsky@pandoracore.com}} 58 | \author[1,3]{Sabina Sachtachtinskagia\thanks{sabina.aueb@gmail.com}} 59 | \affil[1]{Pandora Core AG, Switzerland} 60 | \affil[2]{BICA Labs, Switzerland} 61 | \affil[3]{Athens University of Economics and Business, Greece} 62 | 63 | \date{Version 0.1.0, working draft} 64 | 65 | \begin{document} 66 | 67 | \maketitle 68 | 69 | \begin{abstract} 70 | This work defines Prometheus, a protocol for running high-load \& machine learning computing inside a trustless decentralized environment in Byzantine-tolerant way, utilizing bitcoin blockchain and script functionality, layer 2 state channels, zero knowledge computation integrity arguments, economic incentives and p2p networking. 71 | 72 | This work covers questions of Prometheus design rationale, architecture, formal protocol definition, transaction-based model and specifies protocol operations with demonstrable Nash equilibrium; the latter part is based on our previous work on incentive-based interactive settlement scheme for computation integrity proofs \cite{ibiss}. 73 | 74 | This work will be followed by the papers on (1) specific probabilistically checkable proof schemes for high-load \& machine learning computing, addressing the problems of non-determinism in artificial neural networks, data privacy and federated learning and (2) underlying P2P communication protocol for global state replication and state channel management. 75 | \end{abstract} 76 | 77 | 78 | \section{Background \& Rationale} 79 | 80 | The modern success of cloud computing is related to the economy of scale phenomenon, enhanced by the exponentially increasing amounts of produced data. However, it has created systematic risks and fragility, namely vanishing privacy, possibilities of totalitarian control, surveillance, single points of failure and censorship. It has put at risk the further development of machine learning technologies, which have started to be monopolised together with the access to big data. \href{https://manifesto.ai}{The \#FreeAI Manifesto} \cite{freeai} had declared an initiative to oppose this dramatic trend, and this work aims at the development of the technology stack able to address the issue. 81 | 82 | The problem of censorship-resistant computing consists of many parts, starting from finding and buying information (big data, machine learning models) in a censorship-resistant way, owning it with proper privacy and plausible deniability -- and up to computations using big data in anonymous and censorship-resistant and (desirably) private manner. Prometheus protocol addresses the latter issue, since the former two matters (finding and owning information) can be solved with many other existing initiatives, such as dark/anonymous markets, cryptography technologies, zero-knowledge, distributed storage and data transfer (Torrent, IPFS) etc \cite{ipfs, bittorrent, afs, tor, gnunet}. 83 | 84 | The actual technical problem we need to tackle in order to reach our goal is the proofs for computational integrity (correctness of the actual computations) for the computing performed by some non-trusted (anonymous) third parties -- without the need to repeat the whole volume of the actual computing. This issue is usually addressed by the use of probabilistically checkable proofs (PCP) -- however, they leave untouched the question of coupling the payments for the consumed computational resources with the actual proof. This question was resolved in our previous work \cite{ibiss}. 85 | 86 | Ability to run PCP schemes without trusted checking party provides a way to codify the actual protocol in terms of smart contracts, so it can be used in a very compact form with existing economic blockchain layer. Our approach to protocol design aims at the smallest possible size of the shared system state so it can be implemented with any non-Turing complete smart contract system with storing nothing else than the account balances (or UTXOs) and their un-locking conditions for the involved parties. For example, the protocol can be implemented with the existing Bitcoin script functionality with only two on-chain transactions per whole protocol computing cycle. In such system the PCP proofs are used at the second layer on top of slow blockchain, reducing the footprint, price and increasing scalability for the real-world business. 87 | 88 | \section{Generic Protocol} 89 | 90 | \subsection{Architecture} 91 | \label{architecture} 92 | A core of the protocol is based on the following main algorithms and cryptographic schemes: 93 | \begin{description} 94 | \item[IBISS-CIP] Incentive-based interactive settlement scheme for computation integrity arguments: a game theory model for providing provably-safe economic incentives \cite{ibiss} 95 | \item[Bitcoin] including Bitcoin as a mean of payment, bitcoin blockchain as a safety and immutability layer, Bitcoin Script and HTLC smart contracts for the settlement algorithm logic. 96 | \item[PCP] probabilistically checkable proofs \cite{pcp, pcpibm} as non-interactive computation integrity verification technology 97 | \item[P2P Networking] for building decentralised network of nodes 98 | \end{description} 99 | 100 | The protocol is designed in a modular way, with four main components: 101 | \begin{description} 102 | \item[Settlement algorithm] based on a game theory model with provable Nash equilibrium described in Section \ref{settlement} – an implementation of IBISS-CIP scheme \cite{ibiss} 103 | \item[Transaction model] defining set of interdependent off-chain and on-chain transactions with corresponding HLTV/CLTV/multisig smart contracts, described in Section \ref{transaction_model} 104 | \item[Networking protocol] for P2P node communications and information exchange 105 | \item[HLML-PCP schemes] PCP extension schemes for high-load computing and machine learning-specific tasks (HLML) 106 | \end{description} 107 | 108 | \begin{figure}[h!] 109 | \centering 110 | \begin{adjustbox}{center}\digraph[scale=0.75]{structs}{ 111 | node[shape=record] 112 | prometheus [ 113 | label="{ 114 | {Prometheus protocol} 115 | { Settlement algorithm & Transaction model & HLML-PCP schemes & Networking protocol} 116 | }" 117 | ]; 118 | bitcoin [label="Distributed ledger"]; 119 | pcp [label="PCP"]; 120 | ibiss [label="IBISS-CIP"]; 121 | p2p [label="P2P networking"]; 122 | 123 | prometheus:sc -> bitcoin; 124 | prometheus:zk -> pcp; 125 | prometheus:sa -> ibiss; 126 | prometheus:wp -> p2p; 127 | }\end{adjustbox} 128 | \caption{Architecture of the Prometheus protocol} 129 | \label{fig:architecture} 130 | \end{figure} 131 | 132 | Particularities of specific PCP gadgets for high-load \& machine learning computing, as well as P2P protocol are not covered by these document. 133 | 134 | \subsection{Scopes and Actors} 135 | \label{scopes_actors} 136 | 137 | The protocol operates within two different scopes: \textbf{global scope} $\Gamma$ and \textbf{channel scope} $\Lambda$. 138 | 139 | The protocol design includes the following types of participants (actors): 140 | \begin{description} 141 | \item[Client node] $C$: party prepared to pay for the actual computing and provide necessary data for it. 142 | \item[Worker node] $W$: party prepared to perform actual computing for some reward. 143 | \item[Verifier node] $V$: party prepared to verify the actual computing using HLML-PCP. 144 | \item[Arbiter nodes] $\mathbb{A}$ (global) and their subset $\mathcal{A}$ (for a given computing contract): a special sets of nodes committed to do the arbitration work 145 | \item[Common fund] $F$: used as a wild card destination for penalty payments. This can be a deterministic unspendable contract, or a special contact for funding protocol development etc. The particular value form of common fund is defined by each of Prometheus contracts (see below). 146 | \end{description} 147 | 148 | Clients, Workers and Verifiers (as well as the common funds) operate only within \textit{channel scope}, while Arbiters are defined within the \textit{global scope} (denoted by $\mathbb{A} \mid \Gamma$) and are able to participate in \textit{channel scope} (denoted by $\mathcal{A} \mid \Lambda$). 149 | 150 | \subsection{Layers, Contracts and States} 151 | \label{layers_contracts} 152 | 153 | The protocol operates using different layers of abstraction, each of which contains its own set of contracts: 154 | \begin{enumerate} 155 | \item \textbf{Global consensus state} $\mathsf{G} \mid \Gamma$ based on blockchain-stored state $\Gamma^\Omega$ and off-chain data $\Gamma^\Theta$, committed to the blockchain with hashes and replicated by all parties participating the protocol: 156 | \begin{description} 157 | \item[Prometheus contracts] $\{ \mathsf{P}_i \} \mid \Gamma$: specially-formed contracts encoding pre-defined sets of global parameters. These are \textit{commitment-based agreement}, i.e. agreements that can be referenced by any independent party as a commitment to follow/accept these pre-defined values. Basically, it is a tuple of meta-parameters: 158 | 159 | $\mathsf{P} = \langle w, v, n, a, F, \alpha, \beta, \gamma, \delta, \varepsilon, \mu, \sigma, t_1, t_2, t_3, t_4 \rangle$ 160 | 161 | For the meaning of the constants see Table~\ref{table:state}. 162 | 163 | \item[Arbitration offers] $\{ \mathsf{O}_i \} \mid \Gamma$: specially-formed contracts from parties that want to act as Arbiters in any future computation contract. These contracts are committed to particular Prometheus contract $\mathsf{P}_i$ and must contain proofs of the locked arbiter's stake of size $a$ (defined by $\mathsf{P}_i$): $\mathsf{O} = \langle \mathsf{P}_i, a_p \rangle$. Parties that have made these commitments constitutes global set $\mathbb{A}$. 164 | 165 | \item[Computational contracts] $\{ \mathsf{C}_i \} \mid (\Gamma \vee \Lambda)$: \textit{economically-binding agreements} committed to some particular contract $\mathsf{P}_i$ between parties $C, W, V$ containing proofs of their locked stakes $w_p,v_p$ (corresponding to the amounts defined by $\mathsf{P}_i$), computational reward $c$ and computation-related $\mathtt{payload}$: $\mathsf{C} = \langle \mathsf{P}_i, C, W, V, c, w_p, v_p, \mathtt{payload} \rangle$. Computational contract locks deposits and includes all possible settlement schemes (see Table 2). 166 | 167 | \item[Arbitration contracts] $\{ \mathsf{A}_i \} \mid (\Gamma \vee \Lambda)$: \textit{economically-binding agreements} committed to some particular contract $\mathsf{C}_i$ by Arbiters (denoted as $\mathcal{A}$) that were randomly selected from $\mathbb{A}$ to participate in Arbitration stage of the computing contract. The contract contains proofs of the arbiter's stake commitments ($a_p$): $\mathsf{A} = \langle \mathsf{C}_i, \mathcal{A}, \{ a_{p_i} \mid \forall A_i \in \mathcal{A} \} \rangle$ 168 | \end{description} 169 | 170 | \item \textbf{Multiparty state channel} $\mathsf{M}(\mathsf{C}_i) \mid \Lambda$ originating from each computational contract $\mathsf{C_i}$: $\mathsf{M}(\mathsf{C}_i) = \langle \mathsf{C_i}, \Upsilon, \pi, \mathtt{Encrypt}(\Pi, h_p)\rangle$. The channel operates the following state data: 171 | \begin{description} 172 | \item[Partially-signed transaction tree] $\Upsilon$, which defines: 173 | \begin{itemize} 174 | \item Current \textbf{operational state} of the channel (see below for the details); 175 | \item \textbf{Hash-lock value} $h$ provided by the Worker and used in hash-locked transactions within $\Upsilon$ to bind the use of reward $c$ by the Worker with the ability of the Client to read the results of computation, encrypted with this hash \textit{preimage} $h_p$ (see below); 176 | \item \textbf{Verifier's verdict} $r=\{\emptyset,0,1\}$ on Worker's proofs of computational integrity. Verdict equals to $\emptyset$ before the completion of the Verification phase (see below); 177 | \item \textbf{Set of Arbiters} $\mathcal{A}$ (equals to $\emptyset$ befor the start of arbitration phase); 178 | \item \textbf{State of arbitration contract} $\mathsf{A}_i$ and corresponding signed but unpublished transactions 179 | \item \textbf{Arbitration decision} $d=\{\emptyset,0,1\}$: \textit{economically-binding decision} provided by $\mathcal{A^+}$ (subset of $\mathcal{A}$ which have signed to the decision). Equals to $\emptyset$ before the completion of arbitration phase -- or in case if no definite decision was reached. 180 | \end{itemize} 181 | \item[Non-interactive probabilistic proofs] $\pi$ of computational integrity provided by the Worker at the end of computation phase. 182 | \item[Computation results] $\Pi$ encrypted with \textit{preimage} $h_p$ by the Worker. 183 | \end{description} 184 | 185 | \item \textbf{Internal state} of the actors ($C, W, V, A_i$): each party acts as a part of channel state machine (i.e. it is replicated \& semi-synchroneous state machine). Thus, the internal state of the party is tightly related to the state of the channel (see below). When required, the current state of the party is denoted with precondition notation: for instance, $W\mid \Lambda^\mathsf{C}$ represents Worker node under computing state, while $\Lambda^\mathsf{C} \mid\: W$ represents channel in computing state with Worker node signed confirmation (agreement) on the state published into the channel. 186 | \end{enumerate} 187 | 188 | For the complete list of state parameters see Table~\ref{table:state}. 189 | 190 | \begin{table}[hp] 191 | \caption{Summary of state parameters} 192 | \label{table:state} 193 | \begin{adjustbox}{center} 194 | \begin{tabular}{@{} l m{11cm} m{2.5cm} c @{}} 195 | \toprule 196 | Parameter & Description & Bounding\-conditions & Defined by \\ 197 | \midrule 198 | &\textbf{1. Actors, signatures and stakes} \\ 199 | $W, V, C$ & Worker, Verifier and Client as actors identified by their signatures & $W \ne V \ne C$ & $\mathsf{C}$ \\ 200 | $w, v$ & Stakes deposited by Worker and Verifier & \makecell{$w \gg z$, $v \gg y$,\\ $w \le v$} & $\mathsf{P}$ \\ 201 | $c$ & Amount the Client is willing to pay for the computation & $c \gg z \gg y$ & $\mathsf{C}$ \\ 202 | $z$ & Cost incurred by the Worker for performing the computation & $z \ll c$ & $W$ \\ 203 | $y$ & Cost incurred by the Verifier for performing the verification & $y \ll z \ll c$ & $V$ \\ 204 | $F$ & \textit{Common fund} public key/address which is controlled by external body (can be charity, donations to development, deterministic proof of burn address or anything else) & & $\mathsf{P}$ \\ 205 | $\mathbb{A}$ & Global set of pre-registered Arbiters & $\mathbb{A} \ne \emptyset$ & $\mathsf{O}$ \\ 206 | $\mathcal{A} = \{A_i\}$ & Set of randomly-selected Arbiters as actors identified by their signatures & $\mathcal{A} \subset \mathbb{A}$ $\mid\mathcal{A}\mid\: \ge 3$ & $\mathsf{M}$ \\ 207 | $\mathcal{A^+}$ & Subset of Arbiters that have made a coherent decision & $\mathcal{A^+} \subset \mathcal{A}$ & $\mathsf{M}$ \\ 208 | $\mathcal{A^-}$ & Subset of Arbiters that didn't participate or agreed with a coherent decision & \makecell{$\mathcal{A^-} = \mathcal{A} \setminus \mathcal{A^+}$ \\ $\mathcal{A} = \mathcal{A^+} \cup \mathcal{A^-}$ \\ $\mid\mathcal{A^+}\mid\; > \mu \mid\mathcal{A^-}\mid$} & $\mathsf{M}$ \\ 209 | $n$ & Size of $\mathcal{A}$ (amount of Arbiters participating arbitration) & $3 \le n \ll\: \mid\mathbb{A}\:\mid$ & $\mathsf{P}$ \\ 210 | $a$ & Standard stake of Arbiter locked in blockchain-based contract & $a \gg v$ & $\mathsf{P}$ \\ 211 | \midrule 212 | &\textbf{2. Cryptographic functions and arguments}\\ 213 | $h, h_p$ & Hashed value $h$ and its \textit{preimage} $h_p$ initially selected and known only to the Worker. $h_p$ is used to encrypt the content of the data file. & $h = \mathtt{HASH}(h_p)$ & $W$ \\ 214 | $t_1, t_2, t_3, t_4$ & \textit{Timelock} conditions ordered in such a way that smaller-indexed timelock precedes in time timelocks with larger indexes & $t_i \prec t_{i+n}$ & $\mathsf{P}$ \\ 215 | $T^k_n$ & $k$-of-$n$ threshold multisignature & $n = \mid\mathcal{A}\mid, k = \lceil \mu n\rceil$ & $\mathsf{M}$ \\ 216 | $d$ & \textit{Decision} taken by Arbiters, such as $\mid d=1$ is a pre-condition satisfying that the \textit{voting majority} of Arbiters $\mathcal{A^+}$ found Worker $W$ of being faulty. & $d \in \{0, 1\}$ & $\mathsf{M}$ \\ 217 | \midrule 218 | &\textbf{3. Meta-parameters}\\ 219 | $\alpha$ & Fraction of stake taken from Worker's deposit $w$ in case of its timeout & $0 < \alpha \le 1$ & $\mathsf{P}$ \\ 220 | $\beta$ & Fraction of stake taken from Verifier's deposit $v$ in case of its timeout & $0 < \beta \le 1$ & $\mathsf{P}$ \\ 221 | $\gamma$ & Fraction of Worker's stake $w$ that is awarded to the Client as a compensation payment in case the Arbitation was not being able to reach a final decision & $0 < \gamma < \varepsilon$ & $\mathsf{P}$ \\ 222 | $\delta$ & Fraction of stake $w$ taken from Worker $W$ if it was found faulty by the Verifier and didn't appeal & $\delta \le w-(1-\sigma)c$ & $\mathsf{P}$ \\ 223 | $\varepsilon$ & Fraction of stakes that all participants ($W, V, \mathcal{A}$) are penalised in case of failed Arbitration (i.e. when $\mid\mathcal{A^+}\mid\; < \mu \mid\mathcal{A}\mid$) & $\gamma < \varepsilon \le 1$ & $\mathsf{P}$ \\ 224 | $\mu$ & \textit{Arbiter voting majority}: threshold for Arbiters decision making & $\mu > 0.5$ & $\mathsf{P}$ \\ 225 | $\sigma$ & Fraction of computation used by Worker in its \textit{computation argument} -- and subsequently verified by Verifier. It also defines the proportion of Client's payment $c$ that goes to Worker $W$ in case of successful computing (correspondingly, Verifier $V$ will receive reward of $1-\sigma c$) & $0 \le \sigma \le 1$ & $\mathsf{P}$ \\ 226 | \bottomrule 227 | \end{tabular} 228 | \end{adjustbox} 229 | \end{table} 230 | 231 | Multiparty state channel operates as a deterministic finite state machine with the following possible states (see also Fig.~\ref{fig:states}): 232 | \begin{description} 233 | \item[Setup] $\Lambda^\mathsf{S}$, performed by all parties interactively 234 | \item[Computation] $\Lambda^\mathsf{C}$, performed by Worker 235 | \item[Verification] $\Lambda^\mathsf{V}$, performed by Verifier 236 | \item[Arbitration] $\Lambda^\mathsf{A}$ (optional phase), performed by special group of Arbiters 237 | \item[Closed] $\Lambda^\mathsf{\times}$ with one of the settlement schemes published to the global state $\mathsf{G}$ (for settlement schemes see next section and Table~\ref{table:settlement}). The used settlement scheme is denoted in the subscript of the channel state, i.e. $\Lambda^\mathsf{\times}_\mathtt{3}$. 238 | \end{description} 239 | 240 | State transitions are denoted by arrows with state transition conditions listed above the arrow. 241 | 242 | The normal state transition path is defined by $\Lambda^\mathsf{S} \xrightarrow{\mathsf{C}} \Lambda^\mathsf{C} \xrightarrow{\pi} \Lambda^\mathsf{V} \xrightarrow{r=1} \Lambda^\mathsf{\times}_\mathtt{3}$. 243 | 244 | \begin{figure}[h!] 245 | \centering 246 | \begin{adjustbox}{center}\digraph[scale=0.75]{statemachine}{ 247 | rankdir=LR; rank=same; 248 | { rank=same; 249 | setup -> computing; 250 | computing -> verification [label="proofs"]; 251 | verification -> closed [label="verdict"]; } 252 | setup -> closed [style=dotted, label="no agreement"]; 253 | computing -> closed [style=dotted, label="timeout"]; 254 | verification -> arbitration [label="appeal"]; 255 | arbitration -> closed [label="decision"]; 256 | }\end{adjustbox} 257 | \caption{Possible channel states and transitions} 258 | \label{fig:states} 259 | \end{figure} 260 | 261 | \section{Settlement Algorithm} 262 | \label{settlement} 263 | 264 | Prometheus \textit{settlement algorithm} provides economic incentives and settlement schemes with a provable Nash equilibrium for non-Byzantine behaviour of all of the rational participants. It is developed on top of incentive-based interactive settlement scheme for computation integrity proofs \cite{ibiss}. 265 | 266 | The algorithm runs in five phases (Fig.~\ref{fig:states}), each of which corresponds to particular state of the channel (Fig.~\ref{fig:states}) 267 | 268 | \begin{figure}[hp] 269 | \centering 270 | \includegraphics[height=1.5\columnwidth]{assets/settlementflow.pdf} 271 | \caption{Prometheus settlement algorithm flowchart} 272 | \caption*{\textit{Rectangles corresponds to contract phases and channel states; numbered exists (\#1, \#2 etc) corresponds to the settlement schemes from the Table~\ref{table:settlement}}} 273 | \label{fig:settlementflow} 274 | \end{figure} 275 | 276 | \subsection{Algorithm phases} 277 | \label{phases} 278 | 279 | \subsubsection{Setup -- $\Lambda^\mathsf{S}$} 280 | During the Setup phase, the Client node splits the actual computing task into \textit{batches} suitable for parallel processing in a distributed P2P network. 281 | 282 | For each batch, the client selects Worker and Verifier nodes on some open market or by auction (the actual selection is not part of this protocol). They agree upon the contract conditions (by committing to particular Prometheus contract $\mathsf{P}_i$) and computation reward $c$ in the process of off-chain P2P communications. 283 | 284 | To secure the actual contract Client, Worker and Verifier put $c, w, v$ under the \textit{computation contract} as described in section \ref{layers_contracts} and publish it to the blockchain. 285 | 286 | \subsubsection{Computation -- $\Lambda^\mathsf{C}$} 287 | Worker node downloads all necessary data according to the contract and runs actual computation. Upon their completement the Worker encrypts the results with $h_p$ value, prepares PCP proof $\pi$ with one of the HLML-PCP schemes and updates the state of the channel with these data. The proof is constructed for some pre-defined portion of the data $\sigma$. 288 | 289 | If the phase is not completed within the pre-defined time, the Client or the Verifier has the right to terminate the contract and penalise the Worker (see settlement scheme \#1 in Fig.~\ref{fig:settlementflow} and Table~\ref{table:settlement}) 290 | 291 | \subsubsection{Verification -- $\Lambda^\mathsf{V}$} 292 | Verifier node downloads source data with proofs $\pi$, checks them and reports \textit{verdict} $r$ into the channel. If the Worker found faulty, it has the right to either \textit{appeal} and start Arbitration procedure -- or \textit{admit the fault} by signing another transaction corresponding to settlement scheme \#4 (see Table~\ref{table:settlement}). In this case Worker will have a smaller penalty and we will prevent unnecessary computation load. 293 | 294 | If the phase is not completed within the pre-defined time, the Worker has the right to terminate the contract and penalise Verifier (see settlement scheme \#2 in Fig.~\ref{fig:settlementflow} and Table~\ref{table:settlement}) 295 | 296 | \subsubsection{Arbitration -- $\Lambda^\mathsf{A}$} 297 | Arbiters $\mathcal{A}$ participating the Arbitration phase of the particular computing contract must be chosen from the global arbiters pool/set $\mathbb{A}$ (established well before the initiation of the computing contract) with some deterministic randomness procedure. This is required in order to prevent actors of spamming the Arbiters pool with their agents once the contract has reached Arbitration stage. 298 | 299 | Before become part of the $\mathcal{A}$ each of the selected Arbiters must confirm their participation via off-chain messaging. Jointly Arbiters constituting $\mathcal{A}$ sign their stakes into the computing contract with economically binding contract $\mathsf{A}$ as described in section \ref{layers_contracts} above. 300 | 301 | Arbiters reach decision in process of independent checks of $\pi$ proofs and P2P communications. To reach decision at least $\mu$ part of all Arbiters must come to the same coherent conclusion, where $\mu$ is a so-called \textit{voting majority} -- a parameter defined by Prometheus contract $\mathsf{P}_i$. 302 | 303 | If Arbiters are unable to reach a \textit{coherent decision} ($d=\emptyset$) with $\mu\%$ of votes, the computing contract defaults to payment scheme \#5 (Table~\ref{table:settlement}) where all of the contract participants (except of the Client) are penalised and the Client is compensated with some slice of their stake. 304 | 305 | If the coherent decision has being made, the contract completes with either \#6 or \#7 payment schemes (Table~\ref{table:settlement}) depending on the decision. In both schemes, the parties found faulty are penalised; and it the Worker computation results are found correct, the Worker receives its payment and the Client is provided with the results. 306 | 307 | \subsubsection{Payouts and Channel Closing -- $\Lambda^\mathsf{\times}$} 308 | Depending on the completion of the phases 2, 3 and 4 there might be different ways of the final settlement, numbered on the Fig.~\ref{fig:settlementflow} from \#1 to \#7 and described below in the Table~\ref{table:settlement}. 309 | 310 | The channel is closed by publishing the singed branch of the transaction tree $\Upsilon$ from the channel scope into the global scope: $\Lambda^{\times} \xrightarrow{\Upsilon} \Gamma$. 311 | 312 | In cases when the computations by the Worker were proven to be correct (schemes \#2, \#3 and \#7) in order to take its reward the Worker must publish to the blockchain a spending transaction containing \textit{preimage} $h_p$ used for encrypting the resulting data payload~-- thus allowing Client to read its value and decrypt the data. 313 | 314 | \begin{table}[h!] 315 | \caption{Settlement schemes} 316 | \label{table:settlement} 317 | \begin{adjustbox}{center} 318 | \begin{tabular}{@{} l m{2.5cm} m{5cm} m{3cm} l @{}} 319 | \toprule 320 | ID & Scheme & Payout schedule & \makecell[l]{Precondition\\ $\mid$ postcondition\footnotemark[1],\footnotemark[2]} & Deposit redistribution\footnotemark[1] \\ 321 | \midrule 322 | \#1 & Worker timeout & Penalise Worker with a fraction of stake 323 | & \makecell[l]{$\ldots \Lambda^\mathsf{C} \xrightarrow{\pi=\emptyset}$\\ $\mid\: t_3 \wedge (C \vee V)$ } 324 | & $W: -\alpha w \rightarrow F$ \\ 325 | \midrule 326 | \#2 & Verifier timeout & Pay to Worker, penalise Verifier with a fraction of stake to Client 327 | & \makecell[l]{$\ldots \Lambda^\mathsf{V} \xrightarrow{r=\emptyset}$\\ $\mid\: t_1 \wedge W \wedge h_p$ } 328 | & \makecell[l]{$V: -\beta v \rightarrow C,$\\$C: -\sigma c \rightarrow W$} \\ 329 | \midrule 330 | \#3 & Normal payouts & Pay to Worker and Verifier 331 | & \makecell[l]{$\ldots \Lambda^\mathsf{V} \xrightarrow{r=1}$\\ $\mid\: W \wedge h_p \wedge V$ } 332 | & \makecell[l]{$C: -\sigma c \rightarrow W,$\\$C: -(1-\sigma) c \rightarrow V$} \\ 333 | \midrule 334 | \#4 & Faulty Worker, no appeal & Pay to Verifier from Worker stake, penalise Worker with a fraction of stake 335 | & \makecell[l]{$\ldots \Lambda^\mathsf{V} \xrightarrow{r=0}$\\ $\mid\: t_2 \wedge V \wedge W$ } 336 | & \makecell[l]{$W: -(1-\sigma)c \rightarrow V,$\\$W: -\delta w - (1 - \sigma)c$\\$\: \rightarrow F$} \\ 337 | \midrule 338 | \#5 & Failed Arbitration (no coherent decision) & Penalise all participants, compensate Client 339 | & \makecell[l]{$\ldots \Lambda^\mathsf{V} \xrightarrow{r=0} \Lambda^\mathsf{A} \xrightarrow{d=\emptyset}$\\ $\mid\: t_4 \wedge C$ } 340 | & \makecell[l]{$W: -\gamma w \rightarrow C,$\\ $W, V, \mathcal{A}:$\\$\: -\varepsilon(w+v+\sum a) \rightarrow F$} \\ 341 | \midrule 342 | \#6 & Arbitration proved Worker fault & Penalise Worker with full stake transferred to Arbiters, penalise faulty Arbiters 343 | & \makecell[l]{$\ldots \Lambda^\mathsf{V} \xrightarrow{r=0} \Lambda^\mathsf{A} \xrightarrow{d=1}$\\ $\mid\: T^k_n(\mathcal{A^+})$ } 344 | & \makecell[l]{$W: -w \rightarrow \mathcal{A^+},$ \\ $\forall A_i \in \mathcal{A^-}: -a_i \rightarrow F$} \\ 345 | \midrule 346 | \#7 & Arbitration proved Verifier fault & Pay to Worker, penalise Verifier with full stake transferred to Arbiters and Fund, penalise faulty Arbiters 347 | & \makecell[l]{$\ldots \Lambda^\mathsf{V} \xrightarrow{r=0} \Lambda^\mathsf{A} \xrightarrow{d=0}$\\ $\mid\: T^k_n(\mathcal{A^+}) \wedge W \wedge h_p$ } 348 | & \makecell[l]{$C: -c \rightarrow W$\\$V: -w \rightarrow \mathcal{A^+},$\\ $V: -(v-w) \rightarrow F,$\\ $\forall A_i \in \mathcal{A^-}: -a_i \rightarrow F$} \\ 349 | \bottomrule 350 | \end{tabular} 351 | \end{adjustbox} 352 | \end{table} 353 | \footnotetext[1]{See Table~\ref{table:state} for the summary of the used state parameters} 354 | \footnotetext[2]{The precondition is defined as a postfix of the state transition path in a part that is different from the normal state transition path $\Lambda^\mathsf{S} \xrightarrow{\mathsf{C}} \Lambda^\mathsf{C} \xrightarrow{\pi} \Lambda^\mathsf{V} \xrightarrow{r=1}$. 355 | The postcondition is a set of conditions which have to be satisfied by the computing channel state $\mathsf{M}$.} 356 | 357 | \subsection{Game mechanics} 358 | \label{game} 359 | 360 | To analyse all possible game strategies we need to pay special attention to the timelock postconditions $t_1-t_4$. In fact, their existence splits the whole game into separate timeslots, within which only designated players have ability to "move" (i.e. to sign some particular version of payout scheme or to wait/default/pass move by timeout to the players of the next timeslot). The analysis of this moves and timeslots is given in the Fig.~\ref{fig:strategies}. 361 | 362 | \begin{figure}[h!] 363 | \centering 364 | \begin{adjustbox}{center} 365 | \includegraphics[width=1.2\columnwidth]{assets/strategies.pdf} 366 | \end{adjustbox} 367 | \caption{Possible game strategies} 368 | \label{fig:strategies} 369 | \end{figure} 370 | 371 | At the start of the game (setup phase), a complete set of seven possible payout transactions spending the deposited reward and stakes is created. Each of the transactions is pre-signed by all actors that are \textbf{not} present on the path leading to the settlement scheme corresponding to the transaction. Through the process of game each participant decides which transaction to sign and, by doing so, it adds to the post-condition criteria for the corresponding settlement scheme from the Table~\ref{table:settlement} -- until the completion and publication of one of them. Each signature on the path is equal to the change in the state of the channel and each game end-leaf (exit) is an implementation of some particular payout scheme. 372 | 373 | Thus, by analysing both finite state machine and game theory models we have shown deterministic nature of the settlement algorithm leading to the Byzantine tolerance for the rational set of participants resulting in verified computation and proper reward distribution. 374 | 375 | \section{Transaction model} 376 | \label{transaction_model} 377 | 378 | \subsection{Prometheus contracts} 379 | \label{p_contracts} 380 | 381 | Prometheus contracts $\{\mathsf{P}_i\}$ are defined in the global scope using on-chain transactions $\{ \mathsf{T}_{\mathsf{P}_i} \} \mid\Gamma^\Omega$. Each transaction stores a tuple of contract parameters $\mathsf{P} = \langle w, v, n, a, F, \alpha, \beta, \gamma, \delta, \varepsilon, \mu, \sigma, t_1, t_2, t_3, t_4 \rangle$ in explicit form as part of its single \texttt{OP\_RETURN} output. Explicit storage is required for faster achievement of global state $\mathsf{G}$ syncronisation without requirements to run multiple P2P requests and data keeping. The cost of on-chain storage is low, since each of the Prometheus contracts will define some set of parameters matching well-known best practice and there are just few possible options that can satisfy conditions for the Nash equilibrium. 382 | 383 | Prometheus contracts are committed to by arbitration offer and computational contract originating transactions by their transaction hash (\texttt{txid}, see sections below for the details). 384 | 385 | \subsection{Arbitration offers} 386 | \label{o_contracts} 387 | 388 | Arbitration offers are contracts created by the parties wishing to participate in the future Arbitrations started by Worker appeals under computational contracts (see section Arbitration below). 389 | 390 | Arbitration offer $\mathsf{O}_i$ by a party $A_i$ consists of a commitment to a particular Prometheus contract $\mathsf{P}_x$ and stake proof $a_p$ that corresponds by its value to the parameter $a$ withing the committed contract: $\mathsf{O} = \langle \mathsf{P}_x, a_p \rangle$. This information is packed into a transaction $\mathsf{T_O}$ with $a_p$ amount stored under HTLC P2SH contract in \texttt{scriptPubKey} of its first output and with second output referencing corresponding $\mathsf{T}_{\mathsf{P}_x}$ \texttt{txid} via \texttt{OP\_RETURN} code (see Fig.~\ref{fig:txo}). HTLC type of the contract for the stake lock is required to protect from lateral stake spending during the \textit{computational contract} execution (see \ref{lifecycle} below) and from committing to multiple \textit{computational contracts}. 391 | 392 | The purposes of such transaction is to: 393 | \begin{itemize}[topsep=0pt] 394 | \tightlist 395 | \item Put information into the global state $\mathsf{G}$ about party willing to arbitrate under some specific contract conditions 396 | \item Prove availability of the funds required for creation of arbitration stake 397 | \item Prove time of the arbitration offer (important for achieving Nash equilibrium for the Prometheus settlement algorithms) 398 | \end{itemize} 399 | 400 | \begin{figure}[h!] 401 | \centering 402 | \includegraphics[scale=0.75]{assets/txo.pdf} 403 | \caption{Structure of the arbitration offer commitment transaction $\mathsf{T_O}$} 404 | \label{fig:txo} 405 | \end{figure} 406 | 407 | Only well-formed transactions with unspent output are taken as a part of global state of the system: $(\mathbb{A} \equiv \{ \mathsf{T}_{\mathsf{O}_i} \} \equiv \{ \mathsf{O}_i \mid \Gamma^\Omega \}) \subset \mathsf{P} \subset \mathsf{G}$. 408 | 409 | \subsection{Computational contracts and stage channel lifecycle} 410 | \label{lifecycle} 411 | 412 | \subsubsection{Setup phase overview} 413 | 414 | Channel $\mathsf{M}$ is initiated during its setup phase $\mathsf{M}\mid\Lambda^\mathsf{S}$ off-chain by establishing \textit{computational contract} $\mathsf{C}$ -- multi-party economically-binding agreement between the Client, Worker node and Verifier node. The agreement is established via P2P communication protocol, described in the next chapter of the specification. 415 | Initially, contract in its off-chain version $\mathsf{C}\mid\Lambda^\mathsf{S}$ consists of some selected Prometheus contract $\mathsf{P}_x$, defining main parameters for the contract execution, and initial set of unpublished transactions, namely \textit{commitment transaction} $\mathsf{T_0}$, \textit{arbitration commitment transaction} $\mathsf{T_A}$ and \textit{initial set of settlement transactions} consisting of 8 members $\mathsf{T_{1\dots 8}}$: $\mathsf{C}\mid\Lambda^\mathsf{S} = \langle \mathsf{T_0}, \mathsf{T^\star_A}, \{ \mathsf{T^\star_{1\dots 8}} \} \rangle$ ($\mathsf{T}^\star$ denotes partially-signed transaction). All of these transactions are created and signed by utilising Prometheus P2P protocol. 416 | 417 | \begin{description} 418 | \item[Commitment transaction (notation $\mathsf{T_0}$, txid \texttt{Tx0})] 419 | locks deposit consisting of reward $c$ from the Client and stakes $w, v$ from the Worker and Verifier nodes stored under a single output (see Fig.~\ref{fig:txtree} for the details on transaction structure). As the second output, the transaction contains \texttt{OP\_RETURN} \textttt{scriptPubKey} referencing the hash of the corresponding Prometheus contract $\mathsf{P}$ transaction the participants are committing to. 420 | 421 | \item[Arbitration commitment transaction (notation $\mathsf{T^\star_A}$, txid \texttt{TxA})] 422 | serves the purpose of pre-agreed dispute resolution with economically-binding commitments from all of the participants. Thus, it is fully-signed during the setup phase, and the failure of creating such transaction implies the failure for establishing computational contract: the channel will proceed to the closed state not being published into the global scope. Due to its keystone importance the transaction is created and signed with a special protocol (ceremony), described in the following section. 423 | 424 | \item[Settlement transactions (notation $\{ \mathsf{T}^\star_i \mid 1 \le i \le 8 \}$, txid \texttt{Tx1-Tx8})] 425 | partially-signed transactions, covering all settlement schemes outside Arbitration. They remain unpublished during the channel existence, i.e. reside off-chain in the channel scope as a part of multiparty channel state $\mathsf{T}^\star_{1\dots5} \in \mathsf{M}(\mathsf{C}_i) \mid \Lambda$. Details on these transactions will be covered in the part related to the channel lifecycle. 426 | 427 | \end{description} 428 | 429 | All prepared transactions are organised into partially-signed transaction tree $\Upsilon$ originating from the \textit{commitment transaction} (Fig..~\ref{fig:txtree}). 430 | 431 | \begin{figure}[h!] 432 | \centering 433 | \includegraphics[width=0.9\columnwidth]{assets/txtree.pdf} 434 | \caption{Details on the structure of the transactions inside $\Upsilon$ transaction tree} 435 | \caption*{\textit{To be brief, we have simplified some details in the transaction fields: 436 | amounts with superscripts $x^-$ and $x^+$ signify that the recipient will receive original deposit/stake $x$ either in decreased (slashed) or increased (with some additional payment) form. The exact sizes of the slashes and rewards are provided by the Table~\ref{table:settlement}; 437 | \~ tildes stands for "amount might vary", please check the Table~\ref{table:settlement} for specific amounts for different settlement schemes corresponding to the given transaction ids according to the Table~\ref{table:tx}}} 438 | \label{fig:txtree} 439 | \end{figure} 440 | 441 | \subsubsection{Arbitration commitment ceremony} 442 | \label{ceremony} 443 | 444 | The ceremony must guarantee: 445 | \begin{enumerate} 446 | \item Random selection of Arbiters, that were existed before the creation of the \textit{computation contract} and have committed with some stake. This prevents occupation of the network with pre-registered Arbiters and excludes possibility of the participants to change the existing Arbiters depending on the strategy of contract execution. 447 | \item Commitment from the selected Arbiters to participate in the contract execution. 448 | \item Absence of censorship from one party or any kind of coalition from the contract participants. 449 | \end{enumerate} 450 | 451 | These criteria are satisfied by the following procedure: 452 | \begin{enumerate} 453 | \item A global set of arbiters $\mathbb{A} \mid \Gamma^\Omega$ is known in global on-chain scope before the initiation of the contract and fixed with a snapshot for the full time of contract execution. 454 | 455 | \item All of its participants of $\mathbb{A}$ have committed to the same parameters of the contract (i.e. the same Prometheus contract $\mathsf{P}$) and have locked their stake with a proper \textit{arbitration offer} transaction: $\forall A_i \in \mathbb{A} \mid \mathsf{P}_x: \exists \mathsf{O}_i \mid \Gamma^\Omega = \langle \mathsf{P}_x \dots \rangle$. For details on arbitration offers see the corresponding section in the current chapter. 456 | 457 | \item Deterministic random oracle is utilized by all contract participants to sample $\mathbb{A}$. The simplest form of the oracle is a hash function taken from concatenated string of all \texttt{txid} used by $\mathbb{A}$ participants in their arbitration offer transactions. 458 | 459 | \item Each of $C, V, W$ does the following in an independent manner: 460 | \begin{itemize} 461 | \item Sample set $\mathbb{A}$ in an iterative manner by sending requests to the P2P network and collecting responses of those arbiters who will to participate in the contract. This continues until each of the participants will make a list $\mathcal{A}, |\mathcal{A}|=\mu$ of the parties that have responded to the request. 462 | 463 | \item Present to others participants in $\Lambda^\mathsf{S}$ his own view on $\mathcal{A}$, namely $\mathcal{A}^W, \mathcal{A}^V, \mathcal{A}^C$. 464 | 465 | \item Compute $\mathcal{A}' = \mathcal{A}^W \cup \mathcal{A}^V \cup \mathcal{A}^C$ and reorder it according to the original random sampling order, select subset $\mathcal{A} \subset \mathcal{A}': \mathcal{A} = \{ A_i \in \mathcal{A}': i \le \mu \}$. 466 | 467 | \item Prepare $\mathsf{T^\star_A}$ with all necessary fields (see Fig.~\ref{fig:txtree}) including all of the Arbiters from $\mathcal{A}$ and sign $\mathsf{T^\star_A}$ with each of the $\mathcal{A}$ participants (via P2P communications) 468 | 469 | \item Run Shamir's secret sharing protocol extended with collective secret generation procedure as described in \cite{typhon} across all selected arbiters $\mathcal{A}$ 470 | \end{itemize} 471 | 472 | \item If there were no Byzantine parties, at the end of this ceremony all of participants will have the same version of $\mathsf{T^\star_A}$. 473 | 474 | \item If the version of $\mathsf{T^\star_A}$ does not match between the participants, the channel and computation contract must be closed via $\Lambda^\mathsf{S} \rightarrow \Lambda^\times$ procedure. The Client may try to set up another computing contract by opening new channel and running the same procedure with different $W$ and $V$. 475 | 476 | \end{enumerate} 477 | 478 | \subsubsection{Completion of channel creation} 479 | Transactions, constituting $\Upsilon$ of \textit{computational contract} $\mathsf{C}$ during the setup phase $\Lambda^\mathsf{S}$ must be (partially)signed in the foolowing order: $\mathsf{T^\star_A} \parallel \mathsf{T^\star_6} \prec \mathsf{T^\star_{7,8}} \prec \mathsf{T^\star_{1\dots 5}} \prec \mathsf{T_0}$. This order is important so that inability to successfully accomplish the arbitration commitment ceremony will result in proper channel termination without option for possible Byzantine parties to publish the rest of prepared transactions on-chain and failure channel closure. 480 | 481 | Upon the completion of the $\Upsilon$ construction the original fully-signed \textit{commitment transaction} must be brought into the global space by the Client, putting its last signature upon it. Following publishing of the commitment transaction and its inclusion into the blockchain the transaction becomes \textit{computing contract} as it is seen by everybody in the global on-chain scope $\mathsf{T}_0 \equiv \mathsf{C} \mid \Gamma^\Omega = \langle \mathsf{P}_i, C, W, V, c, w_p, v_p\rangle$ (pls. note that the payload data part of the $\mathsf{C}$ is kept off-chain within the channel scope $\Lambda$, being known only to channel participants). The transaction tree $\Upsilon$ from now till the end of computation and validation stages persists in the state shown on Fig.~\ref{fig:upsilon}. 482 | 483 | \begin{figure}[h!] 484 | \centering 485 | \includegraphics[width=0.75\columnwidth]{assets/upsilon.pdf} 486 | \caption{Transaction tree $\Upsilon\mid(\Lambda^{\mathsf{C}\vee\mathsf{V}} \cup \Gamma)$ during computation and verification channel states} 487 | \caption*{\textit{On-chain/published transactions (thus, defined in $\Gamma^\Omega$ scope) are shown in bold, partially-signed transactions -- with dotted line.}} 488 | \label{fig:upsilon} 489 | \end{figure} 490 | 491 | \subsubsection{Normal channel operation and closure} 492 | Prometheus settlement algorithm is implemented utilising partially-signed transactions from the $\Upsilon$ (Fig.~\ref{fig:upsilon}), prepared at the setup phase by all involved parties. They are consist of two subsets: \textit{pre-arbitration} and \textit{post-arbitration transactions}. 493 | 494 | Pre-arbitration transactions are specified in the Table~\ref{table:tx} and Fig.~\ref{fig:txtree}-\ref{fig:upsilon} by their ids \texttt{Tx1-Tx5}. These transactions cover all settlement schemes outside Arbitration and remain unpublished, i.e. residing off-chain in the channel scope as a part of multiparty channel state $\mathsf{T}_{1\dots5} \in \mathsf{M}(\mathsf{C}_i) \mid \Lambda$. Upon corresponding state transitions from the Fig.~\ref{fig:states} they will be signed by the proper party (see "Post-signed" column in the Table~\ref{table:tx}), and published into the global scope to be included on-chain. This completes computing contract $\mathsf{C}$, invalidates local scope $\Lambda$ and closes the state channel $\mathsf{M}(\mathsf{C})$ according to the corresponding settlement scheme from the Table~\ref{table:settlement}: 495 | 496 | $(\mathsf{T}^\star_j\mid\Lambda) \xrightarrow{C \vee W \vee V} (\mathsf{T}_j \mid \Gamma^\Omega);\enspace \exists j: 1 \le j \le 5\quad \Longrightarrow \quad \mathsf{M}(\mathsf{C}) \mid (\Lambda^{\mathsf{S}\vee\mathsf{C}\vee\mathsf{V}} \rightarrow \Lambda^\times_{\mathsf{1\dots4}})$ 497 | 498 | For the settlement schemes that have to reveal computation results to the client (\#2 and \#3), the signing Worker node must additionally include into the signed transaction \textit{preimage} $h_p$ that was originally used for the results encryption. This is required by unlocking script of \texttt{Tx0} which contains hash-lock conditions in branches related to these settlement schemes (see below section on the unlocking scripts details). 499 | 500 | \begin{table}[h!] 501 | \caption{Settlement transactions and their finalisation conditions} 502 | \label{table:tx} 503 | \begin{adjustbox}{center} 504 | \begin{tabular}{@{} r r c c c c @{}} 505 | \toprule 506 | Id & Payout Schedule & Pre-signed & Post-signed & Hashlock & nTimelock\\ 507 | \midrule 508 | \texttt{Tx1} & \#1 & $W, C$ & $V$ & - & $t_3$ \\ 509 | \texttt{Tx2} & \#1 & $W, V$ & $C$ & - & $t_3$ \\ 510 | \texttt{Tx3} & \#2 & $V, C$ & $W$ & $h_p$ & $t_2$ \\ 511 | \texttt{Tx4} & \#3 & $C, W$ & $V$ & $h_p$ & - \\ 512 | \texttt{Tx5} & \#4 & $C, W$ & $V$ & - & $t_1$ \\ 513 | \texttt{TxA} & \#5-7 & $C, W, A$ & $V$ & $k_p$ & - \\ 514 | \texttt{Tx6} & \#5 & $V, W, A$ & $C$ & - & $t_4$ \\ 515 | \texttt{Tx7} & \#6 & $C, W, V$ & - & $T^k_n(\mathcal{A^+})$ & - \\ 516 | \texttt{Tx8} & \#7 & $C, W, V$ & - & $T^k_n(\mathcal{A^+})$, $h_p$ & w \\ 517 | \bottomrule 518 | \end{tabular} 519 | \end{adjustbox} 520 | \end{table} 521 | 522 | \subsubsection{Arbitration} 523 | 524 | In order to transition the channel state into the Arbitration, $\mathsf{M}(\mathsf{C}) \mid \Lambda^{\mathsf{C}} \rightarrow \Lambda^{\mathsf{A}}$, Worker must submit appeal by including its \textit{arbitration-unlocking preimage} $k_p$ into \texttt{scriptSig} of \texttt{TxA} (which is already signed by the Verifier as part of its \textit{verdict} on the Worker fault) and publishing the transaction: 525 | 526 | $(\mathsf{T}^\star_A\mid\Lambda^\mathsf{V}) \xrightarrow{k_p} (\mathsf{T}_A\mid\Gamma^\Omega) \quad \Longrightarrow \quad\mathsf{M}(\mathsf{C}) \mid (\Lambda^{\mathsf{V}} \xrightarrow{\mathtt{appeal}} \Lambda^{\mathsf{A}})$. 527 | 528 | This signals to the arbiters in $\mathcal{A}$ to initiate their verification procedure on the data from $\mathsf{M}$, mainly PCP proofs $\pi$. 529 | 530 | Arbitration is completed in one of the ways defined in the previous chapter. Each of them has a corresponding pre-signed transaction \texttt{Tx6-8} (Table~\ref{table:tx}), which can be finalised by the interested party and published into the global scope, which will close the channel and complete settlement: 531 | 532 | $(\mathsf{T}^\star_j\mid\Lambda) \xrightarrow{C \vee \mathcal{A}^+} (\mathsf{T}_j \mid \Gamma^\Omega);\enspace \exists j: 6 \le j \le 8\quad \Longrightarrow \quad \mathsf{M}(\mathsf{C}) \mid (\Lambda^{\mathsf{A}} \rightarrow \Lambda^\times_{\mathsf{5\dots7}})$ 533 | 534 | Arbiters that came to the \textit{coherent decision} sign transactions \texttt{Tx7-Tx8} by revealing their parts of the collectively shared secret with a threshold signature $T^k_n$, the corresponding revealed secret is a \textit{preimage} for the hashlock condition in \texttt{scriptSig} part of the transactions. 535 | 536 | \section{Conclusion} 537 | 538 | In the present work we have formally defined Prometheus: a protocol for running high-load \& machine learning computing inside a trustless decentralized environment in Byzantine-tolerant way, utilizing zero knowledge computation integrity arguments, economic incentives and p2p networking. The paper have covered protocol design rationale, architecture, formal protocol definition and specified protocol operations with demonstrable Nash equilibrium, as well as transaction model for implementation with Bitcoin blockchain and script functionality. 539 | 540 | \nocite{*} 541 | \bibliographystyle{abbrv} 542 | \bibliography{references} 543 | 544 | \end{document} 545 | -------------------------------------------------------------------------------- /references.bib: -------------------------------------------------------------------------------- 1 | @article{bitcoin, 2 | title={Bitcoin: A peer-to-peer electronic cash system}, 3 | author={Satoshi Nakamoto}, 4 | howpublished = "\url{https://bitcoin.org/bitcoin.pdf}", 5 | year={2008} 6 | } 7 | 8 | @article{sidechains, 9 | title={Enabling Blockchain Innovations with Pegged Sidechains}, 10 | author={Adam Back and Matt Corallo and Luke Dashjr and Mark Friedenbach and Gregory Maxwell and Andrew Miller and Andrew Poelstra and Jorge Timon and Pieter Wuille}, 11 | howpublished = "\url{https://blockstream.com/technology/sidechains.pdf}", 12 | year={2014} 13 | } 14 | 15 | @misc{ibiss, 16 | title={Incentive-based interactive settlement scheme for computational integrity proofs (IBISS-CIP)}, 17 | author={Maxim Orlovsky and Sabina Sachtachtinskagia}, 18 | howpublished="\url{https://github.com/pandoracore/ibiss-spec/blob/master/ibiss-spec.pdf}", 19 | year={2019}, 20 | organization={Pandora Core AG} 21 | } 22 | 23 | @misc{typhon, 24 | title={Typhon: trustless Bitcoin sidechain protocol}, 25 | author={Maxim Orlovsky}, 26 | howpublished = "\url{https://github.com/dr-orlovsky/typhon-spec}", 27 | year={2019}, 28 | organization={Pandora Core AG} 29 | } 30 | 31 | @article{ipfs, 32 | title={IPFS - Content Addressed, Versioned, P2P File System}, 33 | author={Juan Benet}, 34 | howpublished = "\url{https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf}", 35 | year={2016} 36 | } 37 | 38 | @article{AFS, 39 | title={Scale and performance in a distributed file system}, 40 | author={Howard, John H and Kazar, Michael L and Menees, Sherri G and Nichols, David A and Satyanarayanan, Mahadev and Sidebotham, Robert N and West, Michael J}, 41 | journal={ACM Transactions on Computer Systems (TOCS)}, 42 | volume={6}, 43 | number={1}, 44 | pages={51--81}, 45 | year={1988}, 46 | publisher={ACM} 47 | } 48 | 49 | @inproceedings{bittorrent, 50 | title={Incentives build robustness in BitTorrent}, 51 | author={Cohen, Bram}, 52 | booktitle={Workshop on Economics of Peer-to-Peer systems}, 53 | volume={6}, 54 | pages={68--72}, 55 | year={2003} 56 | } 57 | 58 | @misc{tor, 59 | title={Tor: The Second-Generation Onion Router}, 60 | author={Roger Dingledine and Nick Mathewson and Paul Syverson}, 61 | howpublished= "\url{https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf}" 62 | } 63 | 64 | @article{cloudcomputing, 65 | author="Zhang, Qi 66 | and Cheng, Lu 67 | and Boutaba, Raouf", 68 | title="Cloud computing: state-of-the-art and research challenges", 69 | journal="Journal of Internet Services and Applications", 70 | year="2010", 71 | month="May", 72 | day="01", 73 | volume="1", 74 | number="1", 75 | pages="7--18", 76 | issn="1869-0238", 77 | doi="10.1007/s13174-010-0007-6", 78 | url="https://doi.org/10.1007/s13174-010-0007-6" 79 | } 80 | 81 | @inproceedings{anonymity, 82 | author="Acquisti, Alessandro 83 | and Dingledine, Roger 84 | and Syverson, Paul", 85 | editor="Wright, Rebecca N.", 86 | title="On the Economics of Anonymity", 87 | booktitle="Financial Cryptography", 88 | year="2003", 89 | publisher="Springer Berlin Heidelberg", 90 | address="Berlin, Heidelberg", 91 | pages="84--102", 92 | isbn="978-3-540-45126-6" 93 | } 94 | 95 | @inproceedings{pcpibm, 96 | author="Gennaro, Rosario 97 | and Gentry, Craig 98 | and Parno, Bryan", 99 | editor="Rabin, Tal", 100 | title="Non-interactive Verifiable Computing: Outsourcing Computation to Untrusted Workers", 101 | booktitle="Advances in Cryptology -- CRYPTO 2010", 102 | year="2010", 103 | publisher="Springer Berlin Heidelberg", 104 | address="Berlin, Heidelberg", 105 | pages="465--482", 106 | isbn="978-3-642-14623-7" 107 | } 108 | 109 | @article{cc-censorship1, 110 | author = { Burke T. Ward and Janice C. Sipior }, 111 | title = {The Internet Jurisdiction Risk of Cloud Computing}, 112 | journal = {Information Systems Management}, 113 | volume = {27}, 114 | number = {4}, 115 | pages = {334-339}, 116 | year = {2010}, 117 | publisher = {Taylor & Francis}, 118 | doi = {10.1080/10580530.2010.514248}, 119 | URL = { 120 | https://doi.org/10.1080/10580530.2010.514248 121 | }, 122 | eprint = { 123 | https://doi.org/10.1080/10580530.2010.514248 124 | } 125 | } 126 | 127 | @article{cc-censorship2, 128 | title = "Privacy and security issues in cloud computing: The role of institutions and institutional evolution", 129 | journal = "Telecommunications Policy", 130 | volume = "37", 131 | number = "4", 132 | pages = "372 - 386", 133 | year = "2013", 134 | issn = "0308-5961", 135 | doi = "https://doi.org/10.1016/j.telpol.2012.04.011", 136 | url = "http://www.sciencedirect.com/science/article/pii/S0308596112000717", 137 | author = "Nir Kshetri" 138 | } 139 | 140 | @article{truebit, 141 | title={A scalable verification solution for blockchains}, 142 | author={Jason Teutsch and Christian Reitwießner}, 143 | howpublished="\url{https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf}", 144 | year={2017} 145 | } 146 | 147 | @misc{freeai, 148 | title={The \#FreeAI Manifesto}, 149 | howpublished = "\url{https://manifesto.ai/}", 150 | year={2018} 151 | } 152 | 153 | @misc{webassembly, 154 | title={WebAssembly}, 155 | howpublished = "\url{http://webassembly.org/}", 156 | year={2016} 157 | } 158 | 159 | @misc{pcp, 160 | author = {Eli Ben-Sasson and Alessandro Chiesa and Nicholas Spooner}, 161 | title = {Interactive Oracle Proofs}, 162 | howpublished = {Cryptology ePrint Archive, Report 2016/116}, 163 | year = {2016}, 164 | note = {\url{https://eprint.iacr.org/2016/116}}, 165 | } 166 | 167 | @inproceedings{gnunet, 168 | title={Gnunet -- a truly anonymous networking infrastructure}, 169 | author={Bennett, Krista and Grothoff, Christian and Horozov, Tzvetan and Patrascu, Ioana and Stef, Tiberiu}, 170 | booktitle={In: Proc. Privacy Enhancing Technologies Workshop (PET}, 171 | year={2002}, 172 | organization={Citeseer} 173 | } 174 | 175 | @misc{libp2p, 176 | title={The specs for libp2p and associated submodules.}, 177 | howpublished = "\url{https://github.com/libp2p/specs}" 178 | } 179 | 180 | @inproceedings{kademlia, 181 | title={Kademlia: A Peer-to-peer Information System Based on the XOR Metric}, 182 | author={Maymounkov, Petar and Mazi\`eres, David}, 183 | booktitle={IPTPS '01 Revised Papers from the First International Workshop on Peer-to-Peer Systems}, 184 | pages={53-65}, 185 | year={2002} 186 | } 187 | 188 | @inproceedings{Badertscher, 189 | author="Badertscher, Christian 190 | and Garay, Juan 191 | and Maurer, Ueli 192 | and Tschudi, Daniel 193 | and Zikas, Vassilis", 194 | editor="Nielsen, Jesper Buus 195 | and Rijmen, Vincent", 196 | title="But Why Does It Work? A Rational Protocol Design Treatment of Bitcoin", 197 | booktitle="Advances in Cryptology -- EUROCRYPT 2018 ", 198 | year="2018", 199 | publisher="Springer International Publishing", 200 | address="Cham", 201 | pages="34--65", 202 | isbn="978-3-319-78375-8" 203 | } 204 | 205 | @article{Houy, 206 | title={The Bitcoin Mining Game}, 207 | author={Nicolas Houy}, 208 | journal={Ledger}, 209 | year={2016}, 210 | volume={1}, 211 | pages={53-68} 212 | } 213 | 214 | @book{gametheory, 215 | title = {Game Theory}, 216 | year = {1991}, 217 | publisher = {MIT Press}, 218 | organization = {MIT Press}, 219 | address = {Cambridge, MA}, 220 | author = {Drew Fudenberg and Jean Tirole} 221 | } 222 | 223 | @inproceedings{Kumaresan, 224 | title={How to Use Bitcoin to Incentivize Correct Computations}, 225 | author={Ranjit Kumaresan and Iddo Bentov}, 226 | booktitle={ACM Conference on Computer and Communications Security}, 227 | year={2014} 228 | } 229 | 230 | @book{Laffont, 231 | author = { Laffont, Jean-Jacques, and Martimort, David. }, 232 | title = { The theory of incentives: the principal-agent model }, 233 | isbn = { 0691091838 0691091846 }, 234 | publisher = { Princeton University Press Princeton, N.J. ; Oxford }, 235 | pages = { xii, 421 p. : }, 236 | year = { 2002 }, 237 | type = { Book }, 238 | url = { http://www.loc.gov/catdir/toc/prin031/2001051039.html http://www.loc.gov/catdir/toc/prin031/2001051039.html }, 239 | language = { English }, 240 | subjects = { Economics.; Incentives in industry. }, 241 | life-dates = { 2002 - }, 242 | catalogue-url = { https://nla.gov.au/nla.cat-vn1556459 }, 243 | } 244 | --------------------------------------------------------------------------------