Request for Comment - Distrubited HashTable SC

I am looking for some feedback on some smart contracts that I have developed. I used Truffle and implemented some SCs that I plan on releasing in the near future.

As a former z/OS supervisor core developer, I am in a stage of my career that I want to give back to the open-source community. I find the blockchain technology, particularly Ethereum, quite interesting. The tech is young, and could use some open-source contributions. This post is for me to seek advises on various topics, and feel free to correct my misunderstandings.

First question, I am at a loss as to how I can contribute to the ethereum core dev. How can I get involved? I have a family, and don't have the means to travel to various conferences, especially anywhere far away. So I have to resort to online resources.

Ok, moving on to the SCs. I started with basic data structures within Solidity, and identified the mapping construct as something I want to improve. I think the core EVM could be enhanced to make it better than its current implementation, but I don't know much about the EVM code at this time.

As most people know, unlike hashtables in the real world, mapping in solidity lacks the ability for traversal. This limitation limits the mapping usability for operations that need fast look lookups, and O(n) traversal times.

An naive approach is to store the mapping keys in a LinkedList. One problem with this approach is how to keep the LinkedList and the mapping structures in-sync, especially during element removals. Unless you accept that the LinkedList is not the source of truth, in terms of elements' existence, the monetary cost of looking up the element during removal is too costly. Another problem is regular list traversal. External clients must make numerous, O(n), calls into the EVM to obtain elements. This could be costly in terms of performance. But it is infinitely better than a regular mapping structure.

So I implemented a SC that solves these problems. And I have used it in a couple other proof of concept SCs. One particular called Adminable, which is patterned after the Zeppelin Ownable SC. It basically stores the admin addresses in hash, and maintains state consistence during add and removal operations.

Another SC I created is called Discovery Service. I think of Ethereum VM as a distributed system. And in any DS, you need a good Discovery Service (broker) to provide service lookup abilities. The Ethereum Discovery Service I created allow various distributed services to be indexed, and allows each service to index the service providers it has. In essence, this is a very much like the Distributed HashTable that descibes a swarm of service providers. NTP servers, DNS servers, and many other distributed services can be maintained on the ethereum blockchains.

My questions pertaining to my SCs are:

- Has anyone implemented anything similar, and/or is being used already in the ethereum community? At first I thought Swarm is like the Discovery Service, but after some research, I am not certain that it is.

- I would like my code to be Open Souce code. Meaning I would like a community of developers to help maintain, improve and evolve. With the ability for mappings traversal, the deployed SC instances can be enhanced in the future, provided that the migrations are done correctly. So if done right, I hope the code can evolve and improve through community efforts.

- Currently, the cost of the addition, deletion, lookup is the gas cost of those operations. Although this seems ok for now, but I would like the operation cost to be not pegged against the ethereum market value. Someone suggested having another toke, which just sounds strange, since then the caller has to pay ethereum as well as the token. I have to admit, I am not as familiar with the usecase of tokens in most dapp applicatins. Perhaps someone can really educate me.

- I would like the code to be MIT licensed, but I found Ethereum doesn't have a standard recommended Open Source license. Why?

I have a slack channel setup, I would love more people to join, so it doesn't get too lonely. Feel free to private message me with your comments if you are "shy", or would like to join the channel.

Your comments are much appreciated!


Sign In or Register to comment.