Discover more from DripDropz
Shrinking the Interaction Window
Building Cardano Blockchain Efficiency & Improving Decentralization
Building Cardano Blockchain Efficiency & Improving Decentralization
The Cardano blockchain is experiencing record demand. With that demand, comes long delays in transaction completion, as I wrote about here. Ultimately, this has led to intense competition to get individual transactions on chain, and long backlogs lasting over 24 hours for fulfillment of complex transactions, such as those found in DEXs and DripDropz.
Aren’t all transactions treated equally?
The Cardano blockchain does not currently charge priority gas fees, such as those found on the Ethereum network. Every transaction has an equal chance to arrive on the chain, it simply has to find its way to a mempool, and get in line. Which mempool the transaction ends up in matters! If the mempool is not on a server that is about to produce a block, it will have to wait, or continue looking for a peer that will produce a block soon.
There are two major ways that transactions occur on the Blockchain. Either a simple remittance (Alice Pays Bob 5 Ada) or a more complicated two part transaction. Most Cardano users are currently performing these two part transactions.
Two Part Transactions
If you’ve ever purchased an NFT, or performed a Token Swap at Muesli or Sundae, or Dripped tokens at DripDropz, you have performed a two part transaction! These are currently the most common transaction occurring on the chain, and while your initial transaction that initiates the process is “just” a remittance, the return transaction is generally larger than the initial transaction.
The return transactions are larger because they take advantage of the eUTxO protocol design to complete several similar transactions in a single transaction. DripDropz currently combines two or three standard transactions into one, meaning lower fees for everyone in the transaction, and more efficient processing of the data involved in the transactions. But that begs the question… If putting transactions together is more efficient, why are we having slow downs?
Ultimately, these slow downs are a direct result of decisions made in the design of Cardano Stakepool default setups. The mempool in a standard stakepool setup is tiny, something around 160 KB or 190 KB. So when a Stakepool gets its chance to build a block, that tiny mempool is going to receive a ton of requests, especially during a time of extremely high demand. But once that pool is “full” it can’t add any more. So larger transactions can be shut out, because too many tiny transactions are chasing the precious resource of those mempools.
There is also a performance consideration here. Smaller servers, with less memory and processing power can only fill so much of a block in the time they have allotted to them. So while the extreme energy efficiency of the Raspberry Pi servers support keeping Cardano green, they also may limit the efficiency of some of the blocks being produced in order to get a block into the chain at all.
Slot Battle Royale
The specification for producing a block in a slot is 1 second. Currently the average block is produced in 1.5 to 2 seconds. The remainder of the 20 seconds in each block production time is to allow for other block producers to elect themselves to produce a block with a 95% chance that they won’t collide with the block being produced. This is where Cardano naturally forks to the “correct” best path to keep the network moving forward.
All stakepool operators, regardless of their hardware, should be checking their block propagation time to ensure that they are staying in that range. If you know that you are running your stake pool on the minimum viable hardware, this is an especially important consideration, to ensure that your blocks are full, and out on the network in time.
Full blocks, produced quickly, help reduce delays for everyone.
Binance or Single Pool
You probably noticed that Binance holds the largest chunk of stake delegation, outside of the amalgamation of single pool operators. This is for a simple reason. Binance offers an easy to use product, that offers instant, and automatic staking to end users who are not crypto savvy. Ultimately, they’re doing good business, and being rewarded for it. They are also piled up in very few places on the Internet, making them an easy target for relays.
Single Pool operators offer so much to the community. I know that they are working hard to grow and maintain stake, and there are constant pressures surrounding the ecosystem as we all grow and change. The Single Pool Operator is still the hero of the Cardano blockchain. Most of the Multipool operators likely started with a single pool, and grew larger over time as their popularity increased, or they were selected to be part of other movements within the community.
But this brings us to the shouters. You see, Binance pools are all sitting there, with loads of hash power. There is a large number of pools, all together, that will definitely, absolutely, no question, produce blocks, and lots of them. So developers around the community have taken note of this, and many of them have built relays. These relays do nothing all day long but accept traffic from specific high volume apps, such as minting platforms or lite wallets, and shout that traffic right at the Binance pools.
The products performing this are primarily dealing with those one to one transactions. Short, simple, small transactions. Smart contracts and multi-party transactions don’t get the same benefit for doing this, because of the limited size of the mempools at Binance.
This has been called “clever” or “cheating” depending on who has admitted to doing it, and who hears the admission. That is one of the truths of any group of humans who find themselves tossed together into a community. There will always be someone to disagree with.
A different group within the ecosystem has seen the trend towards building these shouting relays and has dealt with the consequences. Slower completions of multipart transactions, usually only the second part, where the user receives the result of their submission. This is exactly the consequences seen when your DripDropz transaction took an hour or so to start, but several hours, to a couple of days to complete the second portion.
The DripDropz team has learned through extensive experimentation that instead of shouting at the Binance pools, they can put a more targeted, smarter relay next to Single pool operators and help get the transactions that are otherwise being skipped on to the blockchain. This model requires a lot more organizing, and a lot more time for the team to configure, but results in better efficiency for completing transactions that users started.
It’s the UX
The user experience is what is at stake here. Cardano is growing rapidly as new projects take advantage of the Plutus smart contracts, and the Basho performance improvements. As users come online they will demand a reasonable experience of sending a transaction, and receiving a reply within a time frame that they are comfortable with. Recent polling performed by DripDropz showed that time to be less than 1 hour. As we all know, many of these transactions took well over 24 hours during peak demand a few weeks ago.
Not every transaction experiences long delays during periods of high demand. As blocks were examined, we saw numerous blocks with few or no DripDropz transactions, while our internal mempool was growing rapidly. Many of the transactions completing were roughly 2 or 3 hours old, and once we implemented these smart relays, we were able to get transactions into the Blockchain quicker, but still not faster than the transactions in the block just before. So as you can see, DripDropz Relays are actually making the network more fair as older, larger transactions are finally getting a shot to get into the network in a more reasonable time frame.
Organizing Hash or Shouting
Andrew Westberg recently shared a great restaurant analogy for this issue. You’ll have to check out his YouTube to hear him tell it, but here’s a paraphrase:
Imagine that you go to a restaurant and place an order. There is an order taker, and cooks working. You place your order, and stand to the side while one of the cooks begins preparing your order.
Right at that moment, a bus pulls up, and a whole crowd of people enter the restaurant! The order taker continues taking orders, and the cooks continues making orders, but there is no one else there to hand out the orders. So you find yourself waiting longer and longer, while orders just pile up.
If that restaurant was a bit more organized, they would add a few more people to help, or lanes to pick up the food, to make sure that they could serve the whole crowd quickly and efficiently.
Just like the restaurant above, if DripDropz gives Single Pool Operators the opportunity to serve the backlog of traffic from sites with backlogs of large transactions, everyone on the network gets a better, more even user experience.
Now that the team has completed the initial testing with internal pools, DripDropz will run a pilot test with Single pool operators using these smart relays to ensure that traffic is getting closer to the FIFO order that users expect.
Benefits to Single Stakepool Operators
10% increase in drip tokens for all delegates in your pool
Your pool will be included in an exclusive parameter displayed during a token project’s onboarding. (wider variety of tokens for your delegates)
Drip Dropz will advertise your pool on the rotating header banner.
These benefits will go a long way to helping Single Pool Operators grow and maintain their delegated stake, while also improving the transaction efficiency of the whole blockchain.
If you are a Stakepool Operator and are interested in participating in this pilot test, please fill out this form.
Article by Lloyd Duhon.