Developer Q&A

Can you outline the basic functionality of Chain Line?

The basic user journey is: person A wants an item transported and person B is in a place where that item can be purchased or collected. Person B collects the item and pays for it with their own money, and this is then refunded back to them by the smart contract upon delivery to person A.

There were several things that could go wrong here, so I compiled a list of potential problems with the model and figured out solutions to deal with each one. To keep the courier committed to a transaction they have to pay a refundable deposit to the contract when they record their travel dates. Similarly, the recipient of the delivery must reserve the full cost of the item plus a deposit in order to keep their end of the deal.

Once funds have been collected and two users have been matched together, the contract takes care of keeping the funds locked until the item has been delivered successfully. When that happens the courier is refunded for the item and they get a reward on top of that for completing the delivery. The recipient is urged to thoroughly check and test the item before they finalise the transaction.

Who will use Chain Line and how will they benefit?

I wanted to make something that anyone could use and benefit from. That said, I feel Chain Line has a way to go before it becomes attractive to regular people. The original plan was to make a fully peer-to-peer version of the contract so that an item may take multiple hops to reach its destination. That way anybody could join in and contribute to an item’s journey by traveling any leg of the trip.

I feel that the killer feature, which admittedly I have not talked about much, is the fact that items are collected for you by the courier, which means that ordering an item from a physical store in a remote place becomes possible with Chain Line. For anyone who was ever interested in getting their hands on an item that is not eligible for international delivery or is exclusive to one particular country this becomes an attractive option!

What are your plans for ongoing development?

I foresee two phases of future development, and this is ultimately where I would like to take the idea. Right now some immediate work is due in optimising GAS costs to bring the incentivisation and fee structure more in line with comparable services from existing international shipping providers.

The first step is to develop a peer-to-peer shipping network for regular people, which means that travelers use their own luggage space to transport items. Making the contract compatible with a multi-hop journey introduces a lot of complexity as the system must make sure that the item collected is the same one changing hands at each point. I have some ideas around doing this in a low-risk manner and remain open to suggestions!

Beyond that I would like to investigate positioning it as an integrated solution for shipping companies to use to reduce their operating costs. I am no expert in this area but feel that securing the the whole network to make it completely trustless would reduce overhead spent on a) tracking and management systems and b) securing legal contracts with partners.

And, of course, developments in the NEO platform such as NeoID and NeoFS will really improve this concept as a whole. More details are available on the plans for that in the wiki.

What language did you use for development?

The contract is written in Kotlin with unit tests in C#. The web app comes bundled with a modified copy of neon-js to interact with the smart contract.

What SDKs, APIs or frameworks did you use to develop Chain Line?

The website is a React app which is built with Webpack. There is also an express server running in the background serving a web-friendly proxy to a NEO RPC endpoint and an API for getting user wallet balances*. The smart contract was built with “neoj” against the standard devpack SDK for Java, both of which are available as open source projects on GitHub.

I would like to thank CoZ contributors for their work on neon-js as it made it really quite straightforward to get a dApp front-end running. A modified version of this library allows the web app to interact directly with the smart contract via the node’s RPC server.

* Two APIs are used for for additional redundancy when getting wallet balances: NeoScan and the Neon Wallet API.

How would you describe your experience developing on the NEO platform?

I spent the first few weeks researching and putting together a picture in my head of how it all worked, running my node through a debugger to step through the core code and getting my questions answered by helpful people on Slack*. This was my first dApp project and I really wanted to understand how everything worked before diving into the details of the contract.

Documentation was sparse at the time, especially on the Java side of things, and there were absolutely no code examples in Kotlin to speak of. I found this challenging at times but got to resolve a few bugs in the compiler and SDK and fix up a few examples along the way.

The original plan was ambitious (there is a flowchart on the wiki which outlined my original goals) and unfortunately several compromises had to be made due to a lack of documentation and issues with the compiler and SDK taking the time set aside for contract work. I feel the pace of dApp development will increase over time as the platform matures.

Admittedly I had to spend more time in a debugger than was ideal but it’s not often that a developer has a chance to be the first to explore new territory. I enjoyed being able to pick my own language (Kotlin in this case) and am excited for future developments to come from both the core team and CoZ.

* Help, videos and code from @localhuman, @birmas and @wingchan among others come to mind, thanks all!

Could you also add how long you spent on each part of your project, if you remember?

I have a full-time job and had to balance the time invested. The first few weeks were spent solely on design, research and debugging. I started writing the real contract in early October and that took a month or so to finish. The web app, JS library and finishing tweaks to the contract used up the remaining 1½ months before submissions were due.