# Response to ZDAG review and questions by BAT Engineering

ZDAG is an onchain scaling mechanism on the asset layer of Syscoin. Syscoin itself is thought of as “gas” and so our enabling mainly focuses on extending the utility of SPT’s (Syscoin Platform Tokens) whilst keeping the gas cost efficient for scaling payments globally. Two forms of enabling SPTs come in the high-speed interactive payment protocol ZDAG and the trustless bridge to Ethereum, extending that utility to the Ethereum network. Of Course the added security attributes of Nakamoto consensus may also be of interest to ERC20 tokens which have an underlying security domain consistent with whatever Ethereum will decide in Eth 2.0 (sharding, POS).

# Onchain scaling alone is not enough
Onchain scaling is really not enough for global scalable architecture. The premise of blockchain technology is to enable money use-cases which fall short in the face of competition against bandwidth for settlement from a cost perspective. Any multi-party games that depend on limited bandwidth resources will have attack vectors that reduce utility of such a solution. Careful selection of parameters must be done to enable utility at global scale without running into those settlement risk issues. In Bitcoin for example only 1 MB per 10 minutes is allocated and thus even if all transactions were segwit transactions and all done on payment channels (Lightning Networks) and assuming say 2 transactions per person (one to enter payment channel network and one to exist) it will still only be able to serve a fraction of users if it were to be considered the underlying financial network for settling value. Some tradeoffs have to be made in recourse against fully validating and then trusting. There are options such as recursive zkSNARKs/PLONKs, stake weighted, distributed stake weighted (POS + Sharding) but each have their own issues. We feel Nakamoto consensus where all nodes verify then trust is the closest thing to pure decentralized financial networks we can achieve without making tradeoffs. As a base layer for Store of Value these tradeoffs are seen as restricted but where spending and micro-transactions are concerned the tradeoffs are more acceptable. Therefore what we believe is the optimal solution would be to layer the base layer of full decentralized settlement with probabilistic settlement (ZDAG) for micro-transactions. Then further to that we believe most microtransactions will have to be off-chain in order to scale to global levels based on simple arithmetic (7000000000 people doing 2 transactions a day require ~120MB settlement bandwidth every 10 minutes). However because off-chain payments come at a cost of resiliency (payment channel routing, timelock analysis, liquidity requirements), we need a remediation mechanism to further enable payments via an on-chain solution without requiring to sacrifice convenience and waiting for full settlement (confirmations). Of-course macro-transactions will still likely be on-chain and wait for settlement, they are a small percentage of typical transactions. We need a mechanism where macro/micro operate on the same base layer without sacrificing security giving options to transactors based on their preference and risk tolerance for participating in interactive probabilistic transfer of value (onchain or offchain).

So to recap, we envision a solution where assets on Syscoin would leverage payment channels (LN + Assets) but fall back to ZDAG when payment issues arise albeit at a higher cost because its on-chain.

The cost is commensurate with the fee-market that is a tail-end market version of the Bitcoin fee-market. Since one is only concerned with the fact that there will be settlement rather than requiring immediate settlement, the fee would be to have transactions settle eventually rather than fight for immediate placement. It is still the same order of magnitude in complexity and linearly related to the Bitcoin fee market however the specifications were carefully chosen and modelled after assuming global network effect.

# Q&A:
I will answer these under the context of our next release which will convert SPTs to be UTXO based and not account based like they currently are. Doing so will reduce the footprint of specialized consensus of ZDAG and SPT’s since we can leverage the natural DAG ordering of mempool transactions which are hardened with good code coverage (> 90% functional and unit).
> *How is the delay between transactions enforced when multiple parties broadcast new transactions? i.e. it is relatively easy to verify that party A issues N transactions spaced at least by interval A, but it becomes harder to do the same (without really bad QoS) with to ensure interval of transations between M parties.*

The delay is not enforced via consensus. The 10 seconds is arbitrary and wallets can define what that number should be based on preference and perhaps if they are connected to a high speed relayer gateway node. I describe this below. Since the protocol is interactive the merchant software will call a verifyzdag routine which does the following checks (reference code here: https://github.com/syscoin/syscoin/blob/dev-4.x/src/services/rpc/assetrpc.cpp#L143):

* Must be in mempool
* Transaction must be coloured as an SPT transfer (version is set to be an Asset transfer)
* Ensure ZDAG transaction intent is correct. You can transfer an asset as RBF (replaceable) which would be flagged by this routine. Intent to transfer as “ZDAG” would require the transaction to not be replaceable.
* None of the ancestors in the graph of transactions connected to this inputs of this transaction are replaceable. They also have to be SPT transfers themselves, you cannot create a non SPT transfer and spend an input as a non SPT transfer subsequently if you intend to use the ZDAG protocol (chain will validate but the interactive protocol will reject).
* The size of the transaction or any of its ancestors must not exceed MAX_STANDARD_ZDAG_TX_SIZE. Value is 1100 and the safest MTU of an IP packet without fragmentation occurring. This is useful for our gateway relayer described below.
* No mempool conflict found for the inputs of this transaction or any of its ancestors
*Note: we don’t care about descendants of the graph, because they do not affect the ability for a transaction settlement.

> *The optimistic transaction broadcasting seems fragile against attackers. What is the probability of rolling back unconfirmed transactions when the sender is adversarial?*

Yes you are right although we were doing some research on ways to mitigate attacks which are all around DOS vulnerabilities. Signature checks need to happen prior to relay otherwise CPU exhaustion attacks for example are possible if an adversary found a way to time his transactions when nodes change state between relay in parallel vs check then relay. With the efficiency gains of the performant Bitcoin mempool UTXO code and relayer networks this feature could be removed. We no longer do this.

> *In the conclusion: “By using Z-DAG, customers transactions can be settled quickly and with the absolute security proven by Bitcoin.”, this seems an overstatement to me. I’m still not convinced that a merchant can trust unconfirmed transactions with a high degree of confidence. How about if the transaction is broadcasted by adversary nodes that don;t check for the 10s delay, until the transaction arrives to the merchant? How easy is it to perform this attack?*

Yes that sounds like marketing type talk. To be clear, the merchant would naturally hear of the transaction and wait for some time to see if they hear any other transactions (which is why its important to relay first-seen double-spends instead of reject, read below). The delay is thus not enforced by mempool or consensus policy. As long as there is an honest path which is fairly easy to establish as you only need one honest peer connected to the network you will discover both transactions. It is likely not feasible to create sub-networks such that a merchant would not be connected to any honest peers. The merchant is connected to his own peers which adversary has no control of. The core also recycles peers regularily so its not a static list of connections. There are open src tools to double-spend a Bitcoin UTXO and a lot of 0-conf services are now going offline as a result. It is easy to do. The main difference in Syscoin is the propagation of the first double-spend found by a node for an output. Subsequent double-spend transactions that spend an output will follow Bitcoin policy of rejecting/banning peers. In Bitcoin if a transaction does not signal RBF it is not allowed to propagate a double-spend. It is first-come-first-serve. However in our case we do want to see double-spends and we want ZDAG to use non-RBF so a user can’t update the fee and mutate the transaction after the merchant already approved it as safe to accept before confirmation. We do two things to fit this into the Bitcoin model:

1. We propagate the first double-spend a node finds.
2. If a double-spend was to happen, it would have been a transaction where an adversary was able to trick a merchant into sending them a transaction pending an output to the merchant but then sending the same output back to the adversary. However the transaction must follow the verifyzdag rules and thus be limited in size and scope of policy (not-replaceable). Therefore the adversary hopes that the miners and merchant won’t conflict in view of the two transactions even with an enforced delay. The paper goes into some statistics on delay vs probability and percentage of network dissemination of transactions based on those delays.

Typically miners order by feerate but if a conflict is found they will always choose the first one by time regardless of fee ordering.

# Risks, attacks and mitigations

The attack vectors mostly center around the network topology and transaction dessimination. Some other things like collusion with miner are also possible although miner still risks forfeiting PoW in collusion. Bitcoin being merge-mined means that PoW cost is non-negligible. Some research is happening that will enforce miners as well once a double-spend is detected.

Because the main threat model is around network topology we offer incentivized full node with collateral requirements and proof of service (signing a BLS signature in a deterministic quorum once every few hours and committed to a transaction in block enforced by consensus). There are around 2000 of these full node masternodes running on dedicated cloud instances. No other services are required of them so we can maximize throughput and bandwidth consumption for transaction/block propagation.

The main attack vector is if a user consistently has the ability to have the majority of miners see a transaction arrive in different order than a merchant even after the merchant enforces a delay after receiving a transaction from the adversary.

> No thread model?
>
The current implementation uses a [Vyukov](http://www.1024cores.net/home/lock-free-algorithms/queues/bounded-mpmc-queue) bounded MPMC lock-less queue. Single CAS amortized over O(1). However we feel its not needed at the moment. For now we spawn threads based on number of CPU's but generally they are synchronously relayed (input verification of signatures is done asychronously using a basic lock-less thread-pool). We find it to be adequate for decentralized, privacy preserving and DOS resistant propogation which must work harmoniously with block (re)construction. However we can introduce parallel verification and relay via Masternodes which can be implemented as a Proof-of-Service implementation on top of as a [LLQM](https://github.com/dashpay/dips/blob/master/dip-0006.md) (long living quorum) which we have implemented to enforce masternodes to run full nodes. I am not sure it is required in the short or medium term as there are solutions to make the network hear of transactions faster (see below). [The average bitcoin transaction takes roughly 3 seconds](https://www.ece.ubc.ca/~sasha/papers/ccs19.pdf).

# Relayer networks and gateways for faster propagation
The mesh networking topology does a great job on resiliently disseminating information in the face of potential adversaries running faulty nodes. Some other things we are doing to help propagate blocks and transactions quicker (to reduce reorgs and make compact blocks more efficient reducing bandwidth consumption of the network as a whole) is to run a gateway network between major data centers whitelisted and UDP based and is authenticated. Because of this, we can propogate without verification as raw data packets once received by a connected full-node as a source peer, each gateway once received will send the transaction to a locally connected full node instance which will verify and further propogate to its local peers. It is based on Valve’s efficient UDP C++ library which offers UDP packet transfer with sliding window reliability layer similar to Google’s QUIC. https://github.com/syscoin/GameNetworkingSockets

Prototype is here: https://github.com/syscoin/GameNetworkingSockets/blob/master/gateway/gateway.cpp

The idea is with further research merge concepts into a [Bitcoin backbone](https://eprint.iacr.org/2014/765.pdf) type system

The main bottleneck of propagation is the TCP SYN/ACK across the across Pan-Pacific and Atlantic network links as well as verifications across each hop, having a reliable UDP dedicated relay mechanism will help reduce time that Syscoin nodes will hear and have transactions in their local peer groups. The goal is to connect the gateway to a local peer on each instance so it can further disseminate into the local set of peers to reduce delay. Also miners may also run it so other miners can hear of blocks and transactions faster similar to Fibre. Doing so will make the probability of detecting double-spends higher and potentially reduce time merchants may wait.

Specs of Syscoin:

* 16MB of block bandwidth per minute assuming segwit witness carrying transactions.
* SHA256 merge mined with Bitcoin
* UTXO Asset layer, base Syscoin layer shares identical security policies as Bitcoin
* ZDAG on Asset layer, bridge to Ethereum on Asset layer
* On-chain scaling with prospect of enabling enterprise grade reliable trustless payment processing with on/offchain hybrid solution
* Focus only on Simple Value Transfers, MVP of blockchain consensus footprint is balances, and ownership of them. Everything else can reduce data availability in exchange for scale (Eth 2.0 model). We leave that to other designs, we focus on transfers.
* Future integrations of MAST/Taproot to get more complex value transfers without trading off trustlessness or decentralization.
* Zero-knowledge proofs is a cryptographic new frontier, we are dabbling in it to see how we can generalize the concept of bridging and also verifying the state of a chain efficiently. We also apply it in our Digital Identity projects at Blockchain Foundry (a publicly traded company which develops Syscoin softwares for clients).