Prometheus: Scalable High-load Computing & Machine Learning on top of Bitcoin Maxim Orlovsky∗1,2 and Sabina Sachtachtinskagia†1,3 1Pandora Core AG, Switzerland 2BICA Labs, Switzerland 3Athens University of Economics and Business, Greece Version 0.1.0, working draft Abstract 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. 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 [22]. 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.

请翻译

Abstract 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. 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 [22]. 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.

1 Background & Rationale 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. The #FreeAI Manifesto [3] 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. ∗[email protected] † [email protected] 1 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 censorshipresistant 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 [8, 10, 15, 11, 9]. 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 [22]. 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 unlocking conditions for the involved parties. For example, the protocol can be implemented with the existing Bitcoin script functionality with only two onchain 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.

2 Generic Protocol 2.1 Architecture A core of the protocol is based on the following main algorithms and cryp￾tographic schemes: IBISS-CIP Incentive-based interactive settlement scheme for computation in￾tegrity arguments: a game theory model for providing provably-safe eco￾nomic incentives [22] 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. PCP probabilistically checkable proofs [7, 13] as non-interactive computation integrity verification technology P2P Networking for building decentralised network of nodes The protocol is designed in a modular way, with four main components: 2 Settlement algorithm based on a game theory model with provable Nash equilibrium described in Section 3 – an implementation of IBISS-CIP scheme [22] Transaction model defining set of interdependent off-chain and on-chain transactions with corresponding HLTV/CLTV/multisig smart contracts, described in Section 4 Networking protocol for P2P node communications and information exchange HLML-PCP schemes PCP extension schemes for high-load computing and machine learning-specific tasks (HLML)

Figure 1: Architecture of the Prometheus protocol Particularities of specific PCP gadgets for high-load & machine learning computing, as well as P2P protocol are not covered by these document. 2.2 Scopes and Actors The protocol operates within two different scopes: global scope Γ and channel scope Λ. The protocol design includes the following types of participants (actors): Client node C: party prepared to pay for the actual computing and provide necessary data for it. Worker node W: party prepared to perform actual computing for some re￾ward. Verifier node V : party prepared to verify the actual computing using HLML￾PCP. Arbiter nodes A (global) and their subset A (for a given computing contract): a special sets of nodes committed to do the arbitration work Common fund F: used as a wild card destination for penalty payments. This can be a deterministic unspendable contract, or a special contact for fund￾ing protocol development etc. The particular value form of common fund is defined by each of Prometheus contracts (see below). 3 Clients, Workers and Verifiers (as well as the common funds) operate only within channel scope, while Arbiters are defined within the global scope (denoted by A | Γ) and are able to participate in channel scope (denoted by A | Λ).

2.3 Layers, Contracts and States The protocol operates using different layers of abstraction, each of which contains its own set of contracts:

1. Global consensus state G | Γ based on blockchain-stored state Γ Ω and off-chain data Γ Θ, committed to the blockchain with hashes and replicated by all parties participating the protocol: Prometheus contracts {Pi} | Γ: specially-formed contracts encoding pre-defined sets of global parameters. These are 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: P = h w, v, n, a, F, α, β, γ, δ, ε, µ, σ, t1, t2, t3, t4i For the meaning of the constants see Table 1. Arbitration offers {Oi} | Γ: specially-formed contracts from parties that want to act as Arbiters in any future computation contract. These contracts are committed to particular Prometheus contract Pi and must contain proofs of the locked arbiter’s stake of size a (defined by Pi): O = h Pi , api . Parties that have made these commitments constitutes global set A. Computational contracts {Ci} | (Γ ∨ Λ): economically-binding agreements committed to some particular contract Pi between parties C, W, V containing proofs of their locked stakes wp, vp (corresponding to the amounts defined by Pi), computational reward c and computation-related payload: C = h Pi , C, W, V, c, wp, vp, payloadi . Computational contract locks deposits and includes all possible settlement schemes (see Table 2). Arbitration contracts {Ai} | (Γ∨Λ): economically-binding agreements committed to some particular contract Ci by Arbiters (denoted as A) that were randomly selected from A to participate in Arbitration stage of the computing contract. The contract contains proofs of the arbiter’s stake commitments (ap): A = h Ci , A, {api | ∀Ai ∈ A}i

Multiparty state channel M(Ci) | Λ originating from each computa￾tional contract Ci : M(Ci) = h Ci , Υ, π, Encrypt(Π, hp)i . The channel oper￾ates the following state data: Partially-signed transaction tree Υ, which defines: • Current operational state of the channel (see below for the details); • Hash-lock value h provided by the Worker and used in hash￾locked transactions within Υ 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 preimage hp (see below); 4 • Verifier’s verdict r = {∅, 0, 1} on Worker’s proofs of computational integrity. Verdict equals to ∅ before the completion of the Verification phase (see below); • Set of Arbiters A (equals to ∅ befor the start of arbitration phase); • State of arbitration contract Ai and corresponding signed but unpublished transactions • Arbitration decision d = {∅, 0, 1}: economically-binding decision provided by A+ (subset of A which have signed to the decision). Equals to ∅ before the completion of arbitration phase – or in case if no definite decision was reached. Non-interactive probabilistic proofs π of computational integrity provided by the Worker at the end of computation phase. Computation results Π encrypted with preimage hp by the Worker

Internal state of the actors (C, W, V, Ai): 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 | Λ C represents Worker node under computing state, while Λ C | W represents channel in computing state with Worker node signed confirmation (agreement) on the state published into the channel.

For the complete list of state parameters see Table 1. Multiparty state channel operates as a deterministic finite state machine with the following possible states (see also Fig. 2): Setup Λ S , performed by all parties interactively Computation Λ C , performed by Worker Verification Λ V, performed by Verifier Arbitration Λ A (optional phase), performed by special group of Arbiters Closed Λ × with one of the settlement schemes published to the global state G (for settlement schemes see next section and Table 2). The used settlement scheme is denoted in the subscript of the channel state, i.e. Λ × 3 . State transitions are denoted by arrows with state transition conditions listed above the arrow. The normal state transition path is defined by Λ S C −→ Λ C π−→ Λ V r=1 −−→ Λ × 3 .

3 Settlement Algorithm Prometheus 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 [22]. The algorithm runs in five phases (Fig. 2), each of which corresponds to particular state of the channel (Fig. 2)

请翻译 3 Settlement Algorithm Prometheus 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 [22]. The algorithm runs in five phases (Fig. 2), each of which corresponds to particular state of the channel (Fig. 2)

Table 1: Summary of state parameters Parameter Description Boundingconditions Defined by

1. Actors, signatures and stakes W, V, C Worker, Verifier and Client as actors identified by their signatures W = V = C C w, v Stakes deposited by Worker and Verifier w  z, v  y, w ≤ v P c Amount the Client is willing to pay for the computation c  z  y C z Cost incurred by the Worker for performing the computation z  c W y Cost incurred by the Verifier for performing the verification y  z  c V F 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) P A Global set of pre-registered Arbiters A = ∅ O A = {Ai} Set of randomly-selected Arbiters as actors identified by their signatures A ⊂ A | A | ≥ 3 M A+ Subset of Arbiters that have made a coherent decision A+ ⊂ A M A− Subset of Arbiters that didn’t participate or agreed with a coherent decision A− = A \ A+ A = A+ ∪ A− | A+ | > µ | A− | M n Size of A (amount of Arbiters participating arbitration) 3 ≤ n  | A | P a Standard stake of Arbiter locked in blockchain-based contract a  v P
2. Cryptographic functions and arguments h, hp Hashed value h and its preimage hp initially selected and known only to the Worker. hp is used to encrypt the content of the data file. h = HASH(hp) W t1, t2, t3, t4 Timelock conditions ordered in such a way that smaller-indexed timelock precedes in time timelocks with larger indexes ti ≺ ti+n P Tn k k-of-n threshold multisignature n =| A |, k = d µne M d Decision taken by Arbiters, such as | d = 1 is a pre-condition satisfying that the voting majority of Arbiters A+ found Worker W of being faulty. d ∈ {0, 1} M
3. Meta-parameters α Fraction of stake taken from Worker’s deposit w in case of its timeout 0 < α ≤ 1 P β Fraction of stake taken from Verifier’s deposit v in case of its timeout 0 < β ≤ 1 P γ 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 < γ < ε P δ Fraction of stake w taken from Worker W if it was found faulty by the Verifier and didn’t appeal δ ≤ w − (1 − σ)c P ε Fraction of stakes that all participants (W, V, A) are penalised in case of failed Arbitration (i.e. when | A+ | < µ | A |) γ < ε ≤ 1 P µ Arbiter voting majority: threshold for Arbiters decision making µ > 0.5 P σ Fraction of computation used by Worker in its 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 − σc) 0 ≤ σ ≤ 1 P 6

请按照列表展示

3.1 Algorithm phases 3.1.1 Setup – Λ S During the Setup phase, the Client node splits the actual computing task into batches suitable for parallel processing in a distributed P2P network. 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 Pi) and computation reward c in the process of off-chain P2P communications. To secure the actual contract Client, Worker and Verifier put c, w, v under the computation contract as described in section 2.3 and publish it to the blockchain. 3.1.2 Computation – Λ C Worker node downloads all necessary data according to the contract and runs actual computation. Upon their completement the Worker encrypts the results with hp value, prepares PCP proof π 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 σ. 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. 3 and Table 2)

请翻译

setup computing closed no agreement verification proofs timeout verdict arbitration appeal decision Figure 2: Possible channel states and transitions

请根据上面对话内容解释这部分意义

请根据对话详细阐述该图片内容

请用中文详细阐述一下图片过程

Setting up the computation task and agreement on contract conditions between the Client, Worker, and Verifier. Execution of the computation task by the Worker and the requirement of producing proofs. The possibility of a timeout if the computation phase is not completed within a specified time. Verdict arbitration in case of disputes or disagreements during the process. The option for appeal if any party is dissatisfied with the initial decision. Final decision-making process and settlement of the contract.

请翻译

请翻译

3.1.3 Verification – Λ V Verifier node downloads source data with proofs π, checks them and reports verdict r into the channel. If the Worker found faulty, it has the right to either appeal and start Arbitration procedure – or admit the fault by signing another transaction corresponding to settlement scheme #4 (see Table 2). In this case Worker will have a smaller penalty and we will prevent unnecessary computation load. 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. 3 and Table 2) 3.1.4 Arbitration – Λ A Arbiters A participating the Arbitration phase of the particular computing contract must be chosen from the global arbiters pool/set 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. Before become part of the A each of the selected Arbiters must confirm their participation via off-chain messaging. Jointly Arbiters constituting A sign their stakes into the computing contract with economically binding contract A as described in section 2.3 above. Arbiters reach decision in process of independent checks of π proofs and P2P communications. To reach decision at least µ part of all Arbiters must come to the same coherent conclusion, where µ is a so-called voting majority – a parameter defined by Prometheus contract Pi . If Arbiters are unable to reach a coherent decision (d = ∅) with µ% of votes, the computing contract defaults to payment scheme #5 (Table 2) where all of the contract participants (except of the Client) are penalised and the Client is compensated with some slice of their stake. If the coherent decision has being made, the contract completes with either #6 or #7 payment schemes (Table 2) 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. 3.1.5 Payouts and Channel Closing – Λ × Depending on the completion of the phases 2, 3 and 4 there might be different ways of the final settlement, numbered on the Fig. 3 from #1 to #7 and described below in the Table 2. The channel is closed by publishing the singed branch of the transaction tree Υ from the channel scope into the global scope: Λ × Υ −→ Γ. 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 preimage hp used for encrypting the resulting data payload – thus allowing Client to read its value and decrypt the data.

仍然以列表形式阐述下列内容的中文含义

Table 2: Settlement schemes ID Scheme Payout schedule Precondition | postcondition1 , 2 Deposit redistribution1 #1 Worker timeout Penalise Worker with a fraction of stake . . .Λ C π=∅ −−−→ | t3 ∧ (C ∨ V ) W : −αw → F #2 Verifier timeout Pay to Worker, penalise Verifier with a fraction of stake to Client . . .Λ V r=∅ −−→ | t1 ∧ W ∧ hp V : −βv → C, C : −σc → W #3 Normal payouts Pay to Worker and Verifier . . .Λ V r=1 −−→ | W ∧ hp ∧ V C : −σc → W, C : −(1 − σ)c → V #4 Faulty Worker, no appeal Pay to Verifier from Worker stake, penalise Worker with a fraction of stake . . .Λ V r=0 −−→ | t2 ∧ V ∧ W W : −(1 − σ)c → V, W : −δw − (1 − σ)c → F #5 Failed Arbitration (no coherent decision) Penalise all participants, compensate Client . . .Λ V r=0 −−→ Λ A d=∅ −−→ | t4 ∧ C W : −γw → C, W, V, A : −ε(w + v + P a) → F #6 Arbitration proved Worker fault Penalise Worker with full stake transferred to Arbiters, penalise faulty Arbiters . . .Λ V r=0 −−→ Λ A d=1 −−→ | Tn k (A+) W : −w → A+, ∀Ai ∈ A− : −ai → F #7 Arbitration proved Verifier fault Pay to Worker, penalise Verifier with full stake transferred to Arbiters and Fund, penalise faulty Arbiters . . .Λ V r=0 −−→ Λ A d=0 −−→ | Tn k (A+) ∧ W ∧ hp C : −c → W V : −w → A+, V : −(v − w) → F, ∀Ai ∈ A− : −ai → F

3.2 Game mechanics To analyse all possible game strategies we need to pay special attention to the timelock postconditions t1−t4. 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. 4. 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 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 2 – 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 1See Table 1 for the summary of the used state parameters 2The precondition is defined as a postfix of the state transition path in a part that is different from the normal state transition path ΛS C−→ ΛC π−→ ΛV r=1 −−−→. The postcondition is a set of conditions which have to be satisfied by the computing channel state M.

请翻译

3.2 Game mechanics To analyse all possible game strategies we need to pay special attention to the timelock postconditions t1−t4. 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. 4. 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 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 2 – 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 1See Table 1 for the summary of the used state parameters 2The precondition is defined as a postfix of the state transition path in a part that is different from the normal state transition path ΛS C−→ ΛC π−→ ΛV r=1 −−−→. The postcondition is a set of conditions which have to be satisfied by the computing channel state M.

请用中文阐述该图片内容.

请继续翻译 scheme. 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 com￾putation and proper reward distribution. 4 Transaction model 4.1 Prometheus contracts Prometheus contracts {Pi} are defined in the global scope using on-chain transactions {TPi } | Γ Ω. Each transaction stores a tuple of contract parameters P = h w, v, n, a, F, α, β, γ, δ, ε, µ, σ, t1, t2, t3, t4i in explicit form as part of its single OP_RETURN output. Explicit storage is required for faster achievement of global state 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. Prometheus contracts are committed to by arbitration offer and computa￾tional contract originating transactions by their transaction hash (txid, see sections below for the details). 4.2 Arbitration offers Arbitration offers are contracts created by the parties wishing to partici￾pate in the future Arbitrations started by Worker appeals under computational contracts (see section Arbitration below). Arbitration offer Oi by a party Ai consists of a commitment to a particular Prometheus contract Px and stake proof ap that corresponds by its value to the 11 parameter a withing the committed contract: O = h Px, api . This information is packed into a transaction TO with ap amount stored under HTLC P2SH contract in scriptPubKey of its first output and with second output referencing corresponding TPx txid via OP_RETURN code (see Fig. 5). HTLC type of the contract for the stake lock is required to protect from lateral stake spending during the computational contract execution (see 4.3 below) and from committing to multiple computational contracts. The purposes of such transaction is to: • Put information into the global state G about party willing to arbitrate under some specific contract conditions • Prove availability of the funds required for creation of arbitration stake • Prove time of the arbitration offer (important for achieving Nash equilibrium for the Prometheus settlement algorithms)

继续翻译 Figure 5: Structure of the arbitration offer commitment transaction TO Only well-formed transactions with unspent output are taken as a part of global state of the system: (A ≡ {TOi } ≡ {Oi | Γ Ω}) ⊂ P ⊂ G. 4.3 Computational contracts and stage channel lifecycle 4.3.1 Setup phase overview Channel M is initiated during its setup phase M | Λ S off-chain by establish￾ing computational contract C – multi-party economically-binding agreement be￾tween the Client, Worker node and Verifier node. The agreement is established via P2P communication protocol, described in the next chapter of the specifica￾tion. Initially, contract in its off-chain version C | Λ S consists of some selected Prometheus contract Px, defining main parameters for the contract execution, and initial set of unpublished transactions, namely commitment transaction T0, arbitration commitment transaction TA and initial set of settlement transactions consisting of 8 members T1...8: C | Λ S = h T0,T ?A , {T ?1...8 }i (T ? denotes partially￾signed transaction). All of these transactions are created and signed by utilising Prometheus P2P protocol. Commitment transaction (notation T0, txid Tx0) locks deposit consisting 12 of reward c from the Client and stakes w, v from the Worker and Verifier nodes stored under a single output (see Fig. 6 for the details on transaction structure). As the second output, the transaction contains OP_RETURN scriptPubKey referencing the hash of the corresponding Prometheus contract P transaction the participants are committing to. Arbitration commitment transaction (notation T ?A , txid TxA) 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. Settlement transactions (notation {T ?i | 1 ≤ i ≤ 8}, txid Tx1-Tx8) partiallysigned 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 T ?1...5 ∈ M(Ci) | Λ. Details on these transactions will be covered in the part related to the channel lifecycle. All prepared transactions are organised into partially-signed transaction tree Υ originating from the commitment transaction (Fig.. 6).

请翻译

4.3.2 Arbitration commitment ceremony The ceremony must guarantee:

1. Random selection of Arbiters, that were existed before the creation of the 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.
2. Commitment from the selected Arbiters to participate in the contract execution.
3. Absence of censorship from one party or any kind of coalition from the contract participants. These criteria are satisfied by the following procedure:
4. A global set of arbiters A | Γ Ω 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.
5. All of its participants of A have committed to the same parameters of the contract (i.e. the same Prometheus contract P) and have locked their stake with a proper arbitration offer transaction: ∀Ai ∈ A | Px : ∃Oi | Γ Ω = h Px . . .i . For details on arbitration offers see the corresponding section in the current chapter.

Figure 6: Details on the structure of the transactions inside Υ transaction tree To be brief, we have simplified some details in the transaction fields: amounts with superscripts x − and x

• signify that the recipient will receive original de￾posit/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 2; ˜tildes stands for "amount might vary", please check the Table 2 for specific amounts for different settlement schemes corresponding to the given transaction ids according to the Table 3

3. Deterministic random oracle is utilized by all contract participants to sam￾ple A. The simplest form of the oracle is a hash function taken from con- 14 catenated string of all txid used by A participants in their arbitration offer transactions.
4. Each of C, V, W does the following in an independent manner: • Sample set 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 A, |A| = µ of the parties that have responded to the request. • Present to others participants in Λ S his own view on A, namely AW , AV , AC . • Compute A0 = AW ∪AV ∪AC and reorder it according to the original random sampling order, select subset A ⊂ A0 : A = {Ai ∈ A0 : i ≤ µ}. • Prepare T ?A with all necessary fields (see Fig. 6) including all of the Arbiters from A and sign T ?A with each of the A participants (via P2P communications) • Run Shamir’s secret sharing protocol extended with collective secret generation procedure as described in [21] across all selected arbiters A
5. If there were no Byzantine parties, at the end of this ceremony all of participants will have the same version of T ?A .
6. If the version of T ?A does not match between the participants, the channel and computation contract must be closed via Λ S → Λ × 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 .

请翻译 Figure 6: Details on the structure of the transactions inside Υ transaction tree To be brief, we have simplified some details in the transaction fields: amounts with superscripts x − and x

• signify that the recipient will receive original de￾posit/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 2; ˜tildes stands for "amount might vary", please check the Table 2 for specific amounts for different settlement schemes corresponding to the given transaction ids according to the Table 3

3. Deterministic random oracle is utilized by all contract participants to sam￾ple A. The simplest form of the oracle is a hash function taken from con- 14 catenated string of all txid used by A participants in their arbitration offer transactions.
4. Each of C, V, W does the following in an independent manner: • Sample set 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 A, |A| = µ of the parties that have responded to the request. • Present to others participants in Λ S his own view on A, namely AW , AV , AC . • Compute A0 = AW ∪AV ∪AC and reorder it according to the original random sampling order, select subset A ⊂ A0 : A = {Ai ∈ A0 : i ≤ µ}. • Prepare T ?A with all necessary fields (see Fig. 6) including all of the Arbiters from A and sign T ?A with each of the A participants (via P2P communications) • Run Shamir’s secret sharing protocol extended with collective secret generation procedure as described in [21] across all selected arbiters A
5. If there were no Byzantine parties, at the end of this ceremony all of participants will have the same version of T ?A .
6. If the version of T ?A does not match between the participants, the channel and computation contract must be closed via Λ S → Λ × 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 .

3. Deterministic random oracle is utilized by all contract participants to sam￾ple A. The simplest form of the oracle is a hash function taken from con- 14 catenated string of all txid used by A participants in their arbitration offer transactions.
4. Each of C, V, W does the following in an independent manner: • Sample set 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 A, |A| = µ of the parties that have responded to the request. • Present to others participants in Λ S his own view on A, namely AW , AV , AC . • Compute A0 = AW ∪AV ∪AC and reorder it according to the original random sampling order, select subset A ⊂ A0 : A = {Ai ∈ A0 : i ≤ µ}. • Prepare T ?A with all necessary fields (see Fig. 6) including all of the Arbiters from A and sign T ?A with each of the A participants (via P2P communications) • Run Shamir’s secret sharing protocol extended with collective secret generation procedure as described in [21] across all selected arbiters A
5. If there were no Byzantine parties, at the end of this ceremony all of participants will have the same version of T ?A .
6. If the version of T ?A does not match between the participants, the channel and computation contract must be closed via Λ S → Λ × 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 .

4.3.3 Completion of channel creation Transactions, constituting Υ of computational contract C during the setup phase Λ S must be (partially)signed in the foolowing order: T ?A k T ?6 ≺ T ?7,8 ≺ T ?1...5 ≺ T0. 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. Upon the completion of the Υ construction the original fully-signed commit￾ment 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 computing con￾tract as it is seen by everybody in the global on-chain scope T0 ≡ C | Γ Ω = h Pi , C, W, V, c, wp, vpi (pls. note that the payload data part of the C is kept off- chain within the channel scope Λ, being known only to channel participants). The transaction tree Υ from now till the end of computation and validation stages persists in the state shown on Fig. 7. 15 C Tx0 W V commitment A TxA Tx1, Tx2 Tx3 Tx4 Tx5 arbitration Tx6 Tx7 Tx8 Figure 7: Transaction tree Υ | (ΛC∨V ∪ Γ) during computation and verification channel states On-chain/published transactions (thus, defined in Γ Ω scope) are shown in bold, partially-signed transactions – with dotted line. 4.3.4 Normal channel operation and closure Prometheus settlement algorithm is implemented utilising partially-signed transactions from the Υ (Fig. 7), prepared at the setup phase by all involved parties. They are consist of two subsets: pre-arbitration and post-arbitration transactions. Pre-arbitration transactions are specified in the Table 3 and Fig. 6-7 by their ids 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 T1...5 ∈ M(Ci) | Λ. Upon corresponding state transitions from the Fig. 2 they will be signed by the proper party (see "Post-signed" column in the Table 3), and published into the global scope to be included on-chain. This completes computing contract C, invalidates local scope Λ and closes the state channel M(C) according to the corresponding settlement scheme from the Table 2: (T ?j | Λ) C∨W∨V −−−−−−→ (Tj | Γ Ω); ∃j : 1 ≤ j ≤ 5 =⇒ M(C) | (ΛS∨C∨V → Λ × 1...4 ) 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 preimage hp that was originally used for the results encryption. This is required by unlocking script of Tx0 which contains hash-lock conditions in branches related to these settlement schemes (see below section on the unlocking scripts details).

4.3.5 Arbitration In order to transition the channel state into the Arbitration, M(C) | Λ C → Λ A, Worker must submit appeal by including its arbitration-unlocking preimage kp into scriptSig of TxA (which is already signed by the Verifier as part of its verdict on the Worker fault) and publishing the transaction: 16 Table 3: Settlement transactions and their finalisation conditions Id Payout Schedule Pre-signed Post-signed Hashlock nTimelock Tx1 #1 W, C V - t3 Tx2 #1 W, V C - t3 Tx3 #2 V, C W hp t2 Tx4 #3 C, W V hp - Tx5 #4 C, W V - t1 TxA #5-7 C, W, A V kp - Tx6 #5 V, W, A C - t4 Tx7 #6 C, W, V - Tn k (A+) - Tx8 #7 C, W, V - Tn k (A+), hp w (T ?A | Λ V) kp −→ (TA | Γ Ω) =⇒ M(C) | (ΛV appeal −−−−→ Λ A). This signals to the arbiters in A to initiate their verification procedure on the data from M, mainly PCP proofs π. Arbitration is completed in one of the ways defined in the previous chapter. Each of them has a corresponding pre-signed transaction Tx6-8 (Table 3), which can be finalised by the interested party and published into the global scope, which will close the channel and complete settlement: (T ?j | Λ) C∨A+ −−−−→ (Tj | Γ Ω); ∃j : 6 ≤ j ≤ 8 =⇒ M(C) | (ΛA → Λ × 5...7 ) Arbiters that came to the coherent decision sign transactions Tx7-Tx8 by revealing their parts of the collectively shared secret with a threshold signature Tn k , the corresponding revealed secret is a preimage for the hashlock condition in scriptSig part of the transactions. 5 Conclusion 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

请翻译 4.3.5 Arbitration In order to transition the channel state into the Arbitration, M(C) | Λ C → Λ A, Worker must submit appeal by including its arbitration-unlocking preimage kp into scriptSig of TxA (which is already signed by the Verifier as part of its verdict on the Worker fault) and publishing the transaction: 16 Table 3: Settlement transactions and their finalisation conditions Id Payout Schedule Pre-signed Post-signed Hashlock nTimelock Tx1 #1 W, C V - t3 Tx2 #1 W, V C - t3 Tx3 #2 V, C W hp t2 Tx4 #3 C, W V hp - Tx5 #4 C, W V - t1 TxA #5-7 C, W, A V kp - Tx6 #5 V, W, A C - t4 Tx7 #6 C, W, V - Tn k (A+) - Tx8 #7 C, W, V - Tn k (A+), hp w (T ?A | Λ V) kp −→ (TA | Γ Ω) =⇒ M(C) | (ΛV appeal −−−−→ Λ A). This signals to the arbiters in A to initiate their verification procedure on the data from M, mainly PCP proofs π. Arbitration is completed in one of the ways defined in the previous chapter. Each of them has a corresponding pre-signed transaction Tx6-8 (Table 3), which can be finalised by the interested party and published into the global scope, which will close the channel and complete settlement: (T ?j | Λ) C∨A+ −−−−→ (Tj | Γ Ω); ∃j : 6 ≤ j ≤ 8 =⇒ M(C) | (ΛA → Λ × 5...7 ) Arbiters that came to the coherent decision sign transactions Tx7-Tx8 by revealing their parts of the collectively shared secret with a threshold signature Tn k , the corresponding revealed secret is a preimage for the hashlock condition in scriptSig part of the transactions. 5 Conclusion 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.

请根据上面这种双向绑定方法写一页技术白皮书,为比特币的二层网络,提供该技术.该二层网络叫bitscale.

当前这一页纸只需要为bitscale 加上双向绑定通道.

请翻译成中文

上面白皮书中缺乏技术阐述,请加入一些技术性内容.

不需要加入图片,只是该白皮书偏于技术,需要阐明相关技术的实现原理.

这份白皮书并没有阐明我们为什么要用prometheus这种实现方式,而不是使用RSK所阐述的那种实现方式,也没有加入零知识证明作为信任基础.请重写.

请根据上面对话中的prometheus作答而不是云计算的.

这段摘要描述了对于“Prometheus”协议的定义，它是用于在无信任的去中心化环境中以拜占庭容错的方式运行高负载和机器学习计算的协议。该协议利用比特币区块链和脚本功能、第二层状态通道、零知识计算完整性论证、经济激励和P2P网络。该工作涵盖了Prometheus设计原理、架构、正式协议定义、基于交易的模型，并指定了具有可证明纳什均衡的协议操作；后一部分基于他们先前关于基于激励的互动结算方案用于计算完整性证明的工作。这项工作将在接下来出版两篇论文：（1）用于高负载和机器学习计算的特定概率可检验证明方案，解决人工神经网络中的非确定性、数据隐私和联邦学习等问题；（2）全局状态复制和状态通道管理的基础P2P通信协议。

我说的是上面的这个协议

请根据这些写一份关于Bitscale二层网络如何实现双向绑定的白皮书

不需要整个白皮书,我只需要关于双向绑定在bitscale二层网络实现那一页/