DLUX DeFi Progress

avatar
(Edited)

How does this work? Whats done? What's left to do?

Yesterday with the help of a few people ( @elgeko @crimsonclad ) I tested the secured transaction mechanisms and memory management satisfactorily. Allow me to run down why and how these work:

Much like Hive Engine, Decentralized Limitless User eXperiences tokens exist on a "side" chain. Roughly speaking this means that state (the current facts, the state of things) is changed solely by on chain transactions. Where these two protocols differ is Hive Engine is a centralized service, while DLUX aims to be a decentralized service. Relying on the cryptography of HIVE DLUX would meet the standard definition of a block chain.

DLUX Stack

On HE to swap tokens you send a custom JSON or a Hive Transfer and their server reads it and makes changes to their state. If you're Justin Sun or somebody else hated by as few as one person conceivably HIVE engine could confiscate or alter your tokens. DLUX on the other hand is meant to be run by several people. Where much like HIVE itself it would take a majority of witnesses to alter accounts and balances.

Now the tricky part is switching your HIVE tokens for DLUX tokens. Yes, much like bitcoin you can send your tokens to somebody and grow the ecosystem without an automated interface. Price discovery is obscured and easily manipulated. So knowing that every person who runs a DLUX node will also have a Hive account I could take advantage of a key feature available on Hive: Escrow Transactions!

In simple terms running a node is much like playing Settlers of Catan. You have a clearly defined rule book with clearly defined ways to earn points. Now you want to trade some wood(HIVE) for some bricks(DLUX). You can see everybody who is playing. You, Alice, sends an escrow transaction of 1 wood, hoping to receive 2 bricks, to Bob with Charlie as the escrow agent. The rules are simple enough, if Bob or Charlie mishandle the escrow transaction all the players will force them to dump 4 bricks with Alice receiving 2 of the bricks. If Dan, Erin, or Floyd... or even Bob or Charlie wish to spend 2 bricks to get the one wood they'll send a custom Json transaction letting all the player know they accept the terms. All the players adjust the wood/brick balances as the escrow transaction goes through and Bob finally sends the wood to the purchasing player. If the last transfer fails to happen Bob will have 4 bricks subtracted from his balance by all, and two will return to the purchasing player. By collateralizing the transaction the worst that can happen from the point of view of the initial and purchasing players is a failed transaction. From the point of view of the bad actor the best they can do is pay double the listed price for a resource.

The above has been tested for HIVE to DLUX, DLUX to HIVE, HBD to DLUX, and DLUX to HBD. The mediating transactions are all deterministic and expected by all node runners. In addition escrow transactions expire, and users can cancel their own trades. The memory management of this has also been tested.

Now imagine that nobody wants to buy 1 wood for 2 bricks... Dan then posts a trade for 1 wood for 5 bricks. This price condition has decollateralized the first trade. Meaning the best a bad actor can do is beat the current price by 20%. To prevent this trades will not be accepted by the players if they are outside of 20% of the current price; and all current trades will be dropped if the current(volume weighted) price will fall outside of 50-150% of the trade price.

The above restrictions have yet to be fully implemented and tested.

The good news is that this open source mechanism can work to build trustless token markets on HIVE with enough support from the community. What's good for DLUX will be good for everybody who wants to build on Hive. In addition the group of node running the token will also be able to deterministically control a multi-signature wallet. Making even cross chain exchanges(bridges) possible. Chainlink to Hive anybody?

My goal is to build this protocol that can be run by any community.

You can hear more this Sunday at 5PST on The Cryptocurrency Generation in AltSpaceVR hosted by @qwoyn (of @hashkings and @etherchest )



0
0
0.000
19 comments
avatar

Damn had almost completely forgotten about dlux! Nice to read this post!

0
0
0.000
avatar

Guau this Wil help to our lovely hive yo ver the masses, we hope the defi get us the oportunity to enter to this mágic AND until right now áre very expensive.

0
0
0.000
avatar

Great explanation, can't wait to hear more about it on Sunday!

0
0
0.000
avatar

So... we got SMTs?

And also, if cross chain token swaps are so easily done using escrows, why does REN don't just use that to create WBTC? Are there some pros and cons compared to what REN does?

0
0
0.000
avatar

The RenVM is the asset management system for coins off of ETH. The difference between using a node architecture or smart contract based architecture on ETH is what it costs to run the code. GAS is used on ETH, to incentive the entire network to run and verify transactions/code. With DLUX only interested parties make state changes, they are using their Hive Resource Credits for secured cross-talk, while the entire HIVE network verifies only the transactions/cross-talk. Building a bridge between smart contract chains like ETH with DLUX will take quite a bit of work, and due to the nature of Hive/DLUX the bridge will have it's "toll booth" on the ETH side in something like a wrapped DLUX asset.

While the runners of DLUX nodes can deterministically control a Hive multi-sig wallet there would need to be a lot of work done to control a multi-sig wallet on a different chain; but it is possible. It is a long term goal.

0
0
0.000
avatar

Thank you for the detailed answers! It clarifies a lot.

0
0
0.000
avatar

As far as the SMT question goes. This isn't a point by point replacement for SMTs. This costs aditional resources to run and provide token API, as well as Resource credits for the runners. SMTs were going to be run by all HIVE nodes, the cost of running these different tokens would have been reduced by limiting token functions... So in many ways these can be adapted to more uses, and if interested parties are running their token nodes mostly from their at home computers that are always on anyway it would only take a couple hundred HP per node for the Resource credits; while API is provided from a dedicated server(s) to the website(s) relying on the token architecture.

0
0
0.000
avatar

Very very interesting!

runners == nodes which participate / faciliate escrow transactions?

Do these noded need anything from Hive nodes? API, history, ...?

I guess that they will be inexpensive and relatively easy to set up and maintain?

!BEER

0
0
0.000
avatar

As of right now they call out for new blocks. To make some things work like Account Creation Token markets they will need to request some other API from RPCs like... how many ACTs do you have. But once a number is established just reading current blocks should be sufficient to keep things current.

If there is to be a cross chain bridge they'll need to read the blockstream from the other chain as well.

Basically they just need your active key, account name, and possibly memo key depending on how secure some markets need to be. For example, if there is an account creation market running on a side chain somebody would have to send it the new name and public keys for a new account. If this is sent in plain text somebody could swoop your desired name.

0
0
0.000
avatar

Thanks for your answer.

If I understand it correctly, these runners won't need any history of whatever? They'll do just one thing - escrow. At least for Hive based requests.

This seems to be totally lightweight and can be run by anybody:)

I guess You'll need to put more effort/logic in the request distribution and rewards than in escrow confirmation itself :)

0
0
0.000
avatar

For the DEX aspect of things you're correct. Theres about 5 transactions that need to happen per swap.
DLUX -> Hive:
CustomJson to list a swap 0a(lay tx)
Escrow Transaction to purchase a swap 0b(lay tx)
Escrow Approval 1&2(.agent and .to)
Escrow dispute 3(.to ->ensures no further action is required from either lay party)
Escrow release 4(.agent funds ->.to account)
Transfer 5(.to -> 0a's account)

The reverse looks about the same except the escrow transaction happens first, followed by approvals. Then the Custom Json happens to inform how to complete the chain.

I have it set up to even distribute an inflation pool of DLUX for completed txs as these require RCs. In effect you are mining for DLUX with RCs.

DLUX is meant to help decentralize content storage and serving for dlux.io (VR/AR/WebApps via IPFS) so theres a bunch of other things happening in my chain.

0
0
0.000
avatar

That's great. A huge potential.

OK, I won't bother you with silly questions any longer. At least not this week :)

Have a great weekend and good luck!

0
0
0.000
avatar

Congratulations @disregardfiat! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :

You received more than 2250 upvotes. Your next target is to reach 2500 upvotes.

You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

Do not miss the last post from @hivebuzz:

It's today! Do not miss the opening of HiveFest⁵
0
0
0.000
avatar

I'm not that technical, but it do looks competing with engine, and that's interesting. Looking forward to it.

0
0
0.000
avatar

Do you have the login option disabled on dlux.io? If I try to login it asks me if I want to download keychain but I already have the extension installed and I don't see any other option.

0
0
0.000
avatar

I'm aware of this issue. For some reason or another firefox isn't playing as nice as chrome/brave. Also 100% of the UI on DLUX is in the alpha/beta stage. Just barely working enough to help test the back end, and give users an idea of what to expect.

0
0
0.000
avatar

You need to stake more BEER (24 staked BEER allows you to call BEER one time per day)

0
0
0.000