Manipulated AND not Manipulated does not equal false! — How the inability of Ethereum to support multiple dimensions changes a design
As Carl Sagan might have said if he were a developer: If you want to make a decentralized platform from the scratch, you should start from building the assembly. The problem of this universe in relation to Ethereum’s assembly is that we currently do not have the multi-dimensional arrays. I never liked the fact that we do not have negative numbers, no doubles, and now, nothing beyond a 1D array (for some types) — a huge WTF !??? How is this thing even supposed to solve complex problems we have today that are trust-related when we cannot even trust Ethereum to be able to solve them ? Well, the only way it can solve the complex problems is if we break them into simpler problems and have a wallet ready to pay for the solution.
Alright, that means just one thing. Back to the drawing board, and do some more hacking just to make the simple and the basic things work. Maps are the data-types that we can use, assuming some maximum number of dimensions (that is, maps of maps of… maps). However, this is not a good approach since we would need to add the 1D data per dimension rather than adding the multi-dimensional data at once (again, the big cost issue).
Good news is that Ethereum crew is currently working on solving this problem and it is in the highly experimental stage of a development. In the meantime, we must rely on the Ethereum’s engineering skills, and create a system that is more flexible. This means, that for each data-type array (that is uint, string, byte, bool, …) we can have a separate contract where we can add and/or change the data like we would using the SQL. Alright, so how do we solve the lack of multi-dimensional arrays? Well, this means adding one more uint variable. 0 means it is a 1 dimensional array. 1 means that each element in array is an array, 2 means that each array has two elements and so on. The problem is that the array growth is exponential and that it really is hard to format it all and make some sense out of it while doing the computations. Therefore, it costs two updates instead of one, while the external agent needs to interpret and format the data. I would rather wait for Ethereum crew to finish their experimental work than complicate it further. Another issue is the data access, but I will not talk about it now.
If we introduce this map and build the logic around it, we have solved half of the problem:
mapping(address => mapping(uint => byte)) byteDataArray;
If we say that address is the msg.sender (the address that uses the contract) uint is some ID and byte is the data we wish to read/write, we can create the logic that is able to allow the contract creator manipulate the data. On the other hand, we can ask the contract not to allow the owner to be able to manipulate the data and keep up with the decentralized ideology.
There are pros and cons to both. For example, imagine the framework sold to someone who becomes the authority with a simple goal in mind: — to destroy the project and make the competitor grow, to everyone else’s disadvantage. In this situation, we do not want the power to manipulate the data. On the other hand, imagine someone supporting the wrong causes that may bring harm to people (human trafficking, and so on…). In that case, we would need the centralized authority to be able to manipulate the data.
Alright, why not have both ! It is very simple. Just create one contract that allows the manipulation and other that does not, while focusing the development in any direction that seems to be the best approach. Both of these contracts can be connected to another contract making the call to either of the other two contracts. In the meantime, we can also wait for the Ethereum engineering crew to start supporting the multiple dimension arrays, and then simply add the next set of contracts that use those arrays. The next problem is, do we just leave the database open for anyone to read/write to it, while focusing only on one or the other type of a database while developing the platform? If we do, it means that anyone can use the token and develop their own malicious platform around it. If we don’t, we are facing the same issue like we did at the very beginning and haven’t solved anything at all. I am leaving it open. It is the solution because if someone wanted to build their own malicious platform, they could just copy-paste the code, do some changes, and make a separate project. Furthermore, as the decentralized coding progresses and becomes more complicated, this issue will become pointless to even talk about.
This is how the need for a decentralized database will be solved, while this approach will be applied developing the final product.