An infrastructure layer on Ethereum Network for better DApps
We introduced Dagger days ago and people have been using it since then. We would like to have this opportunity to explain more about Dagger and how you can use it for your own product.
Understanding Ethereum transactions
Before we try to explain about Dagger, one should understand how Ethereum transaction works.
Ethereum has two types of addresses — Accounts and contracts. Both looks the same — 40 characters long hex string. Difference is that contracts do have code associated with it while accounts don’t.
One can use accounts or contracts to transfer Ethereum from or to accounts and contracts. Simple. But when contract receives a transaction, Ethereum runs piece of code on contract, depending upon the “function and parameters” provided in transaction. You send a transaction to 0x contract to transfer — X amount of ZRX to 0x123…890 address. “transfer” is a function and “X” and “0x123…890” are parameters. You keep changing the parameters to transfer different amount of tokens to different people.
Contract also contains user defined logs, which are included in transaction receipt when you do the transaction. Example — ERC20 token standard defines two events. One of them is “Transfer”. When you transfer tokens to anyone, “Transfer(from, to, amount)” log occurs and gets included in the transaction receipt and the block.
If user wants to transfer X amount of ZRX from address A to address B, transaction procedure would be —
- User creates transaction saying, transfer X amount of ZRX to address B. And sets the target address as ZRX contract address.
- User signs the transaction with private key of address A and broadcast the transaction to Ethereum network.
When the transaction gets included in the block after 15 seconds or so, anyone can find the receipt with log “Transfer(A, B, X)” in it (if transaction was successful). It’s important to note that user’s transaction may fail if they don’t have enough ZRX tokens and log will never happen.
What is Dagger?
Dagger is simple tool, built on top of Ethereum Network. It provides a way to listen incoming and outgoing transactions from accounts and contracts, and as well as logs.
With Dagger, if you subscribe certain kind of topics, then whenever transaction occurs which complies with subscribed topics, you get a message.
Dagger provides variety of topics to listen multiple things, including new blocks, incoming/outgoing transactions, new receipts, event logs (with and without filter) and contract creation.
There are two top level of topics you can subscribe to: Latest and Confirmed. We called them: Rooms.
Ethereum block needs certain amount of confirmations to make them irreversible. When two different blocks get created at same time, only one gets included in final longest Ethereum blockchain.
Dagger considers newly created block as latest block (shown as red in illustration) and issues messages in latest room.
After 12 confirmations when it becomes confirmed (shown as green in illustration), Dagger issues same messages again in confirmed room.
Confirmation is a new block being found and added to the end of the blockchain after our targeted block which included our TX. Some exchanges wait for 30 confirmations, but we think 12 confirmations is pretty safe for now.
Which room should you use? Most of the time, you can use latest room. The confirmed room is for irreversible and critical task, like sending money, generating invoices, sending emails or issuing another dependent transaction. If you cannot decide if it’s critical or not, use confirmed to be safe.