The ACES team has spent the month since the release of the Ethereum encoded listener discussing its strengths and weaknesses. During this time, we created a plan of action to bring better functionality and user experience to the ACES ecosystem.
Here are some of the key areas we identified and how we are addressing them in our near term plan.
1) Setting up a node was too difficult for most people, despite our best efforts to make a very clear guide. It is important that setting up a node be extremely simple if we are to stay within the mantra that ARK and ACES should provide the best user experience across all cryptocurrencies. As a result, we have developed a plan to make ACES services “one-click”, or close to it, such that interested service providers can launch any of the developed services from a simple admin panel, similar to how Linode, AWS, and DigitalOcean allow users to launch servers.
2) Finding providers was too difficult. Even those who had succeeded in setting up a node didn’t really find themselves with any demand for their service. As a result, we will be creating a marketplace to allow any user to search, filter, review and interact with all compatible ACES nodes.
3) Developers didn’t have a clear path to creating their own services. To help developers, we will be building service APIs and encoded listener APIs so that developers can get started building whatever encoded listener they want, and they will be confident their application will be compatible with the ACES marketplace.
4) Input forms may not be the most convenient for users. Users may sometimes have a better experience if they can interact with encoded listeners exclusively through the ARK desktop wallet (or any ARK wallet, for that matter). To help with this, we will develop a framework for “formless functions.” These are functions that can be used on the ARK blockchain without ever needing to define the fields on a form to receive a special SmartBridge vendor field. Instead, users can interact with an ACES node by sending SmartBridge functions, like ‘Send 2 eth to 0x23f29023f’, with the required amount of ARK… no form necessary.
5) There was significant demand for a Bitcoin encoded listener. As a result of this demand, and to help quicken the adoption of ACES services and the marketplace, we will be developing a Bitcoin encoded listener.
6) Transfer services did not function “two-way”. Many users wanted to utilize ACES services to move from Ether to Ark, or from Bitcoin to ARK. Our proof of concept only did one-way transfers of ARK to Ether. We will be building two-way listener services so that nodes can accept Bitcoin to send ARK, or accept ARK to send Bitcoin.
7) Nodes were not trustless. We are keeping a very close eye on ARK developments like ArkVM, which would allow us to build trustless nodes. In the meantime there are several other implementations we can do to move towards trustlessness. One implementation includes creating Solidity-based smart contracts for service collateral. Initially, these can be built on Ethereum, and later migrated to ArkVM implementations when the technology is ready. This side of the technology would not impact service consumers, rather it would be relevant to service providers. I will go into more detail on these concepts in a later blog post.
