A Design For An Efficient Coordinated Financial Computing Platform


Table Of Contents


Fig 1: Masternode setup

Syscoin Platform

  • UTXO Assets
  • Compliance through Notary
  • Fungible and Non-Fungible tokens (Generic Asset infrastructure named SPT — Syscoin Platform Tokens)
  • Z-DAG for fast probabilistic onchain payments, working alongside payment channel systems like Lightning Networks
  • Deterministic validators (Masternodes) which run as Long-Living Quorums for distributed consensus decisions such as Chain Locks
  • Decentralized Governance, 10% of block subsidy is saved to pay out in a governance mechanism through a network wide vote via masternodes
  • Merged-mined with Bitcoin for shared work alongside Bitcoin miners

Masternode Configuration

Chain Locks

Blockchain as a Computational Court

Fig 2: Four-layer tech stack

Scalability and Security


State Liveness and State Safety

  • State Liveness — Transferring coins in a timely manner
  • State Safety — Private custody

Avoiding Re-execution of Transactions

Fig 3: Host and EVM layer

Validity Proof Systems Overtop Proof-of-Work Systems

Quantum Resistance:

Table 1: Estimates of quantum resilience for current cryptosystems (see [20])
Fig 4: zkSync Rollup design

A Design Proposal for Web 3.0

  1. [Host Layer] Bitcoin’s design is the gold standard for security and decentralization. Proof-of-work and Nakamoto Consensus settlement security are widely regarded by academics as the most hardened solution for ledgering value [23]. It’s possible this may change, however it’s also arguable that the intricate design encompassing Game Theory, Economics, risk reward ratios for attack, and the minimal amounts of compromising attack vectors is likely not to change for the foreseeable future. UTXO’s (and payments with them) are more efficient than account-based or EVM-based. That said, Bitcoin itself suffers from not being expressive enough to build abstraction for general computation.
  2. [Operating System Layer] EVM/eWASM is the gold standard for general computation because of its wide adoption in the community. Anyone building smart contracts are likely using this model or will continue to use it as the standard for autonomous general computation with consensus.
  3. [SDK Layer] Zero-knowledge proofs are the gold standard for generalized computation scaling for blockchain applications. They enable one-time execution via a prover and enable aggregate proof checking instead of re-execution of complex transactions. zk-STARKs or zk-SNARKs using collision resistant hash functions that work with only weak cryptographic assumptions and therefore are quantum safe. At the moment generalized smart contracts are not there yet but we are quickly approaching the day (eg, Cairo, Zinc) when there will be abstractions made to have most Solidity code trans-compile into a native zero-knowledge aware compiler similar to how .NET runtime and C# allows an abstraction on top of C/C++ as an interpretive layer on top
  4. [Application Layer] Verticals or applications applying the above SDK to define business goals.
Fig 5: Proposed design
  1. Miner of the EVM chain collects the latest block hash and places it into the Syscoin block.
  2. When validating Syscoin blocks, nodes confirm the validity of the EVM tip by consulting the EVM chain software locally.
  3. Fees for the EVM chain are to be paid in SYS. We need an asset representing SYS on the EVM chain, which will be SYSX. We will enable this through a similar working concept that we’ve already established (SysEthereum Bridge). We may also enable pre-compiles on the EVM chain side to extract Syscoin block hashes and merkle roots to confirm validity of SYS to SYSX burn transactions.
Fig 6: Merge mining on Syscoin

Optimistic vs ZkRollup

  • Eliminate a nasty tail risk: theft of funds from OR via intricate yet viable attack vectors;
  • Reduce withdrawal times from 1–2 weeks to a few minutes;
  • Enable fast tx confirmations and exits in practically unlimited volumes;
  • Introduce privacy by default.

Decentralized Cost Model

State-less Layer 1 Design

Related Works

Commercial Interests

Functional Overview

Fig 7: High-level description
  1. The root hash of the subtree of the shard S must be published once, as calldata on L1. This guarantees that users of all other shards will be able to reconstruct their part of the state.
  2. The smart contract of the data availability policy of this shard must be invoked to enforce additional requirements (e.g. verify the signature of the majority of the shard consensus participants).
  1. Non-committee, non fraud proof based consensus for data availability checks. No ⅔ online assumption; see ethresear.ch post [30].
  2. Sublinear block validation of ZKP system. Use something like Lazy Ledger as a data availability proof engine and majority consensus; see ethresear.ch post [31].
  3. Use a combination of above, as well as masternode quorum signatures for any of the available quorums to sign a message committing to data availability checks as well as data validity. Using masternodes can provide a deterministic set of nodes to validate decisions as a service. The data can be stored elsewhere accessible to the quorums as they reach consensus that it is indeed valid and available.

Give Me The Goods

Table 2: Gas costs and Total throughput

Blockchain Foundry




Syscoin Core Developer and Foundation President

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store