Jag Sidhu
    • Create new note
    • Create a note from template
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Engagement control Commenting, Suggest edit, Emoji Reply
      • Invitee
      • No invitee
    • Publish Note

      Publish Note

      Everyone on the web can find and read all notes of this public team.
      Once published, notes can be searched and viewed by anyone online.
      See published notes
      Please check the box to agree to the Community Guidelines.
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Emoji Reply
    • Enable
    • Versions and GitHub Sync
    • Note settings
    • Engagement control
    • Transfer ownership
    • Delete this note
    • Save as template
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
Versions and GitHub Sync Engagement control Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Engagement control Commenting, Suggest edit, Emoji Reply
Invitee
No invitee
Publish Note

Publish Note

Everyone on the web can find and read all notes of this public team.
Once published, notes can be searched and viewed by anyone online.
See published notes
Please check the box to agree to the Community Guidelines.
Engagement control
Commenting
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
  • Everyone
Suggest edit
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
Emoji Reply
Enable
Import from Dropbox Google Drive Gist Clipboard
   owned this note    owned this note      
Published Linked with GitHub
Subscribed
  • Any changes
    Be notified of any changes
  • Mention me
    Be notified of mention me
  • Unsubscribe
Subscribe
# 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).

Import from clipboard

Advanced permission required

Your current role can only read. Ask the system administrator to acquire write and comment permission.

This team is disabled

Sorry, this team is disabled. You can't edit this note.

This note is locked

Sorry, only owner can edit this note.

Reach the limit

Sorry, you've reached the max length this note can be.
Please reduce the content or divide it to more notes, thank you!

Import from Gist

Import from Snippet

or

Export to Snippet

Are you sure?

Do you really want to delete this note?
All users will lose their connection.

Create a note from template

Create a note from template

Oops...
This template is not available.
Upgrade
All
  • All
  • Team
No template found.

Create custom template

Upgrade

Delete template

Do you really want to delete this template?
Turn this template into a regular note and keep its content, versions, and comments.

This page need refresh

You have an incompatible client version.
Refresh to update.
New version available!
See releases notes here
Refresh to enjoy new features.
Your user state has changed.
Refresh to load new user state.

Sign in

Forgot password

or

By clicking below, you agree to our terms of service.

Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
Wallet ( )
Connect another wallet

New to HackMD? Sign up

Help

  • English
  • 中文
  • Français
  • Deutsch
  • 日本語
  • Español
  • Català
  • Ελληνικά
  • Português
  • italiano
  • Türkçe
  • Русский
  • Nederlands
  • hrvatski jezik
  • język polski
  • Українська
  • हिन्दी
  • svenska
  • Esperanto
  • dansk

Documents

Help & Tutorial

How to use Book mode

How to use Slide mode

API Docs

Edit in VSCode

Install browser extension

Get in Touch

Feedback

Discord

Send us email

Resources

Releases

Pricing

Blog

Policy

Terms

Privacy

Cheatsheet

Syntax Example Reference
# Header Header 基本排版
- Unordered List
  • Unordered List
1. Ordered List
  1. Ordered List
- [ ] Todo List
  • Todo List
> Blockquote
Blockquote
**Bold font** Bold font
*Italics font* Italics font
~~Strikethrough~~ Strikethrough
19^th^ 19th
H~2~O H2O
++Inserted text++ Inserted text
==Marked text== Marked text
[link text](https:// "title") Link
![image alt](https:// "title") Image
`Code` Code 在筆記中貼入程式碼
```javascript
var i = 0;
```
var i = 0;
:smile: :smile: Emoji list
{%youtube youtube_id %} Externals
$L^aT_eX$ LaTeX
:::info
This is a alert area.
:::

This is a alert area.

Versions and GitHub Sync
Upgrade to Prime Plan

  • Edit version name
  • Delete

revision author avatar     named on  

More Less

No updates to save
Compare
    Choose a version
    No search result
    Version not found
Sign in to link this note to GitHub
Learn more
This note is not linked with GitHub
 

Feedback

Submission failed, please try again

Thanks for your support.

On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

Please give us some advice and help us improve HackMD.

 

Thanks for your feedback

Remove version name

Do you want to remove this version name and description?

Transfer ownership

Transfer to
    Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

      Link with GitHub

      Please authorize HackMD on GitHub
      • Please sign in to GitHub and install the HackMD app on your GitHub repo.
      • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
      Learn more  Sign in to GitHub

      Push the note to GitHub Push to GitHub Pull a file from GitHub

        Authorize again
       

      Choose which file to push to

      Select repo
      Refresh Authorize more repos
      Select branch
      Select file
      Select branch
      Choose version(s) to push
      • Save a new version and push
      • Choose from existing versions
      Include title and tags
      Available push count

      Upgrade

      Pull from GitHub

       
      File from GitHub
      File from HackMD

      GitHub Link Settings

      File linked

      Linked by
      File path
      Last synced branch
      Available push count

      Upgrade

      Danger Zone

      Unlink
      You will no longer receive notification when GitHub file changes after unlink.

      Syncing

      Push failed

      Push successfully