The structure of this event will be very similar to dARCH Event 0. The major difference is going to be that the entries have to use the service model. The total prize pool for this testnet event will be 1,000 DERO
Round 1
Developers will have 3 weeks to develop and share their service.
The first round of judgment is on functionality only, not UX/UI.
5 Winners of 80 DERO each.
Round 2
All 5 winners from round 1 will progress to round 2 and they will have an additional 3 weeks to further develop their ideas. Their idea must maintain a at least the same functionality as the original POC but new features can be added.
3 Winners as follows:
1st Place 300 DERO
2nd Place 200 DERO
3rd Place 100 DERO
Round 1 entries must be made posted on this DERO forum post on or before 7PM UTC, May 1st, 2021. Judges will be the DERO developers and foundation with heavy consideration of input from the community.
Why services?
Services allow developers to use whatever language they choose in order to interact with the DERO network using websockets. This means that developers do not need to use DEROBASIC or DVM in order to create applications or services.
More info on the DERO service model can be found here :
Here is a placeholder for my competition entry: Ether Seller.
The service is operated by a person who wants to sell Ether for Dero automatically, without using an exchange. The service accepts a fixed amount of Dero (e.g. 1 Dero) and replies with a secret key (hash) that can be used to redeem a fixed amount of Ether (e.g. 0.01 Ether) from an Ethereum smart contract.
The mechanism works as follows: a series of key pairs are generated, secret and public. Each public key is a SHA-256 hash of the corresponding secret key. The public keys are stored in an Ethereum smart contract. The secret keys are stored in the service database. When the service receives the correct amount of Dero, it replies to the transaction with one of the secret keys. The buyer can then use this key to redeem a fixed amount of Ether from the Ethereum smart contract. The redemption process requires two stages, to prevent a third party from potentially grabbing the secret key in the Ethereum transaction pool and then paying a higher transaction fee to steal the Ether. Further details of this will be published in Round 2.
One significant limitation of this service is that users must trust the service provider: there is potential for the service provider to take the Dero and not provide the secret key. So it is not as secure as an atomic swap. In reality, this type of service provider would probably operate within a community where feedback from users can be posted, and transaction amounts would likely be small, to limit losses in the event of fraud.
The service source code will be uploaded to github nearer the Round 1 competition deadline of 1st May, and a service address posted for people to try out.
If the service makes it to Round 2 of the competition, I will develop the Ethereum smart contract and post a live version on one of the Ethereum public testnets, to demonstrate a fully working system between the two blockchains.
The configuration involves a few pieces such as client services to be ran and hosted locally (similar to a local installation/use of Outlook or other platforms), as well as (V2) a server-side service which will handle unique usernames (V2-pending) and/or other methods for “contact lookup” , but the server service never hosts any encryption/decryption details for your messages (V1 is just deto / dero address).
Each client will have a local site, self-signed cert (V2) most likely or other method, in which will be a simple interface for interacting with their email clients. You can perform 3 separate actions: register (V2 - registering your user address/integrated address to a friendly name [V2-pending], this also validates whether a recipient is valid on sending), get emails (get emails sent to you and decrypt them), send emails (send emails to recipients).
V1: Client enters deto/dero address(s) for contacts; V2: client A gets integrated address (of client B) from server side service via the normal deto address or username [V2-pending] (sent via COMMENT to integrated service addr and returned integrated via response).
Client A encrypts message and sends to SC , STORE() as some random “key” (ensure it doesn’t exist in SC first) and the text of the message is AES-256 encrypted [future pending other methods/alternatives/compression etc.] chacha20poly1305 encrypted (derohe/cipher.go at main · deroproject/derohe · GitHub)
Client A sends COMMENT with variable and decrypt key (formatted: var1/mykey [hex encoded make([]byte, 32, 32)]) for specific message (random decrypt every time) to integrated addr of Client B (received from step 1)
Client B received tx with var / decrypt key and gets message and decrypts to be viewed.
V1 Summary: Clients share keys directly via rpc_COMMENT. Messages are encrypted with unique keys for every message (persists keys via tx look back and SC variable lookup).
V2 Summary: Server service knows no difference other than integrated addr for deto addresses (to be replaced with username or other unique id services in future), clients share keys directly. Messages are encrypted with unique keys for every message (persists keys via tx look back and SC variable lookup)
Here is a placeholder for my competition entry: swap_xmr_dero
The dero’s user send some dero to the service, then the service request the tradeogre api to get the rate dero/xmr, and it send monero to the user’s address.
More info in readme.md.
This is a prototype. Do not use in any mainnet.
I need a feature to detect new block and new tx to make it better.
Don’t know if this is gonna be my final entry, since I’m already invested in my NFT project and might want to continue that. Maybe you guys can decide what you find cooler.
Anyway, here’s a little play project I developed to test the limits (or lack thereof) of the service protocol.
File Sharing over Dero network
Allows wallets to share actual files between each other.
No matter the file type, no matter the extension, and no matter the size.
In fact, the “limit” of ~128 bytes per payload is easily “bypassed” by splitting the files into multiple parts, sending them in multiple TXs, and re-assembling them together on the receiving end.
A final TX with the SHA256 checksum of the file is also sent to the receiver so that the client can verify the integrity of the file.
Of course, the larger the file is, the more it’s going to cost to send it and the more it’s going to bloat the chain. On testnet it’s just 0.00001 DERO per TX; on mainnet I expect there will be higher fees. Therefore, WHENEVER possible, users should avoid using this system and stick to IPFS/something else.
However, if someone really wants to make use of a private peer-to-peer file transfer over a secure network like Dero, they technically can and this prototype shows how. It supports both text and binary (encoded in base64) files.
Oh, and on an important note - that will sound obvious to those who know how the protocol works - sender and receiver don’t need to be online simultaneously in order for the file transfer to happen.
A marketplace based on Smart Contracts will be available to list anyone offering this service.
To register as an exit node provider, you will just have to register with the service address and put your asking price for 1GB of bandwidth and your location.
A user wishing to use a VPN must register with the service by making a transaction from his DERO address with the DERO amount to calculate his bandwidth credit.
Based on wireguard, a gui client will be built to be easier to use it.
I’m not sure this qualifies as a Service in its current state, but the project aims to include a collection of Services dApp developers can easily integrate (e.g. npm install ckd-react) into their apps. Regardless, thought I’d post here.
I’m not the best writer, so I did a video to go into details: