Development Update #1

Written by Tulio Braga (CTO at Swapy Network)

Swapy Exchange Public Alpha Version

This is our first development update since we launched our public alpha (v0.0.1). From the start, our app relied in some off-chain services. We decided to go for a full decentralization model, what mean we refactored our code to use only on-chain information as a source to the Swapy Exchange. This decision brings advantages and challenges we will briefly describe in this post. But first…

We would like to invite you to try our alpha and provide a feedback.

Swapy Exchange Interface

Changelog

See below a summary of our latest Swapy Exchange D’App and Swapy Exchange Protocol improvements:

1. Browser version available;
2. Metamask integration;
3. Decentralized the login (using Metamask wallet as identification);
4. Consuming data directly from contracts (refactored all services that still relied in centralized endpoints);
5. Implemented the protocol return flow as well as its behavior on the D’App;
6. Added “Total returned” and “Total to be returned” on credit companies dashboard;
7. Separated “Gross return” into “Received gross return” and “Expected gross return” on investors dashboard;
8. Cleaned up contracts’ code by creating a solidity library to support our protocol interactions;
9. Implemented the contract methods to provide Swapy Tokens as collateral within the protocol;
10. Implemented the contract methods to exchange assets (buy/sell) between the investors.

Advantages of full decentralization

By completely decentralizing our app, we removed the need for centralized servers to provide us with data and authentication. Since the mechanism of private and public keys are enough to identify the user in cryptographic protocols, why would we need a central authentication service? We removed the need for typing passwords and usernames on every log in action, a legacy from our demo version. This makes things much easier for our users, as well as guaranteeing a good level of pseudonymity, transparency, and security, as expected on decentralized apps. Also, we reduced the costs with infrastructure and guaranteed the access to Swapy Exchange to the community since there is no controlling organization that can interfere with it. Everything is directly read from and write to the Ethereum blockchain.

Regarding the application data (e.g.: fundraising assets, investments), we decided to consume it directly from the contracts on the blockchain. This way we can guarantee a 24/7 uptime, remove the difficulty of creating and maintaining services to make sure that the off-chain data is synchronized with the blockchain, and reduce the chances of data inconsistencies. Of course, it imposes some challenges such as dealing with the cost of data read, for example. But since it makes more sense in the decentralized world, facing this challenges is basic. It is important to say that we are not storing unnecessary data into the smart contracts.

Challenges

As said, one of the biggest challenges of the full decentralization in our case was the cost of data read. In the earlier days of our refactoring, we saw ourselves struggling with lots of RPC calls to Infura nodes as well as first loading all asset contracts to then filter by the attributes we needed. To deal with this, we faced a trade-off between minimizing the gas or duplicating the events both in our asset contract and in our controller contract (SwapyExchange.sol). Since the gas differences seemed to be minim, we decided to refactor our code. This way we were able to add filterable values to the controller contract’s events making it less expensive to load data (loading only the needed assets). Furthermore, we decided to benchmark the cost of reading either attribute by attribute or multiple attributes at once through a contract method. We found out that in some cases it makes more sense to read one by one, while in other cases it may be less expensive to call a function and return all the values need through a single request.

Although we managed to get a good speed to load data from the nodes, we believe we will get to this challenges again in other further circumstances. One development proposal we discussed past weeks that may improve the speed of data read is to deploy our own infrastructure of global nodes and scale it as most as we need. This may also provide us with better control of software updates and new Ethereum features. It is enough to give our users the speed they desire to have when using our D’Apps, while we can also explore off-chain caching strategies to load data upfront.

—

Overall, we achieved full decentralization on Swapy Exchange maintaining a good user experience, reducing the costs with infrastructure, and extinguishing the chance of inconsistencies. We will keep exploring alternatives to provide a good read speed as well as minimizing gas, with 100% decentralization. Keep on track!

We hope you enjoy the news. Let´s go Change the world!

—

NOTE: We are still hosting our browser version on traditional cloud (centralized servers). However, we are providing desktop versions for Windows, Linux, and Mac that do not rely on any sort of centralization. Also, since our project is open source, anyone can clone and run it locally.

Learn more about Swapy Network:

Website
Twitter
Telegram (Announcements only)
Telegram (Open chat)