Aragon SubnetDAO implementation

[Sebohe]

This topic will contain the implementation logs of the following topic:

New user router, Eth, IP address provision

This is how people get a new router, an IP address for it, and get onto their local Althea network. Nate goes on a website showing the Althea global TCR, and finds a subnet DAO serving his area. He goes to a meeting or whatever, and talks to Judy, who is one of the organizers. He decides to get on the subnet and get a router from her. Now there are several requirements: Nate’s router needs an Ethereum address. Nate’s router’s Eth address needs to have enough funds to cover the IP leasing/ren…

---

---

The first version of the implementation had ethereum addresses and ip addresses in a dynamic array. This first version was more of hello world experiment to understand aragon interface.

The reasons for using a dynamic array was to make it easier to obtain all of the contents of the list to display within the Aragon app, since obtaining the same values from a solidity mapping is not possible. One can’t ask for the whole mapping. The problem of using arrays is that it consumes more gas and to check whether and address is in the array one would still have to iterate over it.

After some discussion the Aragon app won’t display all of the members of the list. It will instead just have an input to check whether the IP address and the matching ethereum address exists in the list. (Maybe there is a way of displaying the current neighbors and put a nice green checkmark if they are in the subnet dao)

By using ipv6 the chances of a collision are much higher so it is easier to just generate the ipv6 address locally and then check if the address already exists in the list. If if does exist then just generate a new ipv6 address.

The next iteration of the smart contract will have:

• mapping(ipv6_type => address)
• a delay before removing a node from
• a renewal fee for staying on the list

Also, the application should be running completely on Rinkeby sooner rather than later that way routers can check against the list.

[Jehan]

@Sebohe

The next iteration of the smart contract will have:

mapping(ipv6_type => address)
a delay before removing a node from
a renewal fee for staying on the list

I’d like to clarify- that delay is not necessary if we are using the randomization technique. Also the renewal fee will be dealt with separately.

The next version should have:

• mapping(ipv6_type => address)
• button to check if address is on list as discussed above

The version after that will generate ip addresses randomly on the front end, and check that they are within a range in solidity, but don’t worry about that now.