# SuperContracts(SC) Development Status(17.12.20)
The document provides a detailed analysis of the current SC layer status. It precisely describes observed obstacles for development continuance and suggests a high-level development plan for resolving them.

## Current Barriers

### Pervasive Storage Dependence
Most parts of current SCs implementation internals are fully dependant on Storage. Considering its ongoing reimplementation to meet likely the final design, it is clearly seen that SCs internals are affected drastically. Still, the Storage and its components are the base and there is simply no sense in touching SCs core components, before finishing it. If most of the Storage components are not ready or at least not pending major changes, then the development of SCs would be redundant work. Unluckily, we already experienced that with the current implementation and a decent part of the existent work will be removed, because SC development was started too early - before Storage reached its final form.

### Unfinished Design
SCs design has undescribed gaps that are necessary to assemble the whole picture for SCs. Filling them through the development process is not obvious and forces us to design solutions ourselves.

Also, recently we've had our regular meeting with researchers where they mentioned their awareness of unresolved problems in SCs. We haven't gone into specifics, as we had a different main topic to discuss, but anyway they should confirm SCs incompleteness as well.

Unresolved gaps we observe:
- There is no description for inter SuperContract interactions, thus the current implementation lacks that as well. An example of those limitations is the inability to implement the DEx contract because calling other token contracts e.g. ERC20 is not possible. In general, the interaction between smart contracts is what makes them such powerful technology and there are other useful use cases other than DEx. Also, there are no specifics regarding how contracts should interact on the SuperContracts code level, especially how incode API should look like for developers and how to handle gas costs of those API calls.

- There is no detailed description of the flow for a Bulk update in the SC case. Flow described from the client's perspective is superfluous for SC usecase and should be revisited.

- Our technical paper presents Multidrive SuperContract, but the document with its description does not have any design, only the high-level idea, thus it is not ready.

- There is no design of some interactions between any user and SuperContract. Let's look at a simple smart contract logic example: "when a user executes a payable function within any smart contract, the smart contracts system/tooling automatically sends a required amount of tokens from the user's to the contract's account". The current design misses a description of: (1)How SuperContract should cost-effectively store the history of tokens sent by any user in his state. The current described solution writes state into a JSON file, thus writing the state only increases the file, thus every new transfer made by any user incrementally increases the cost for parsing the JSON file, making SuperContract non-usable. (2)How any SuperContract developer should specify some function as payable? Without this (3)we can't automatically send tokens for user accordingly to the called function. Also, instead of "payable" there might be other "..able"s to describe what transactions(global chain state change) should be sent from the user's account.

### Human Resources Deficiency
One of the biggest issues is plainly a lack of experienced hands able to handle SC development. Anatoliy is the only developer for the layer, but he is also extremely experienced in the other layers. Considering that current priorities are addressed on Storage and Chain base layers in the first place, he is totally irreplaceable on that front. He is the only one who can handle Storage token economy and Chain <-> Storage relations. Also, through the experience, we observe that spreading efforts and switching contexts between layers at the same time is bug-prone, thus ineffective. Consequently, Anatoliy is fully focused on Storage until all the required work connected with the Chain is done. Hence, we have nobody to elaborate on SCs.

In the same way, there is a bottleneck for researchers to finish the SC design, as they work part-time and do not have enough resources to allocate for the SC layer.

### Unsupported Virtual Machine Dependecy
The main reason why we must not use the current VM is that it is not being updated with WASM format specs corrections. WASM is a relatively new format and it has not reached a finished state and is updated usually. Those updates also include security fixes, thus we already relying on possibly insecure dependency, which will never be fixed. Another reason is that unsupported or deprecated software brings unpredictability and carries over responsibility from unexpected internal issues to the users, like us. If we rely on such software, we may encounter them, or may not, but considering the code quality I saw after reading some part of their codebase, I can simply conclude - issues are likely to appear. This reason is an example of how low-level stuff may affect long-term plans by bringing unpredictability that can't be overseen. Security breaches from the initial reason, in the same way, might be found at the later points of the platform's life, but the solution would be very internal and complex to fix quickly, while the breach is continuing to be abused. The overall point here is not to rely on such uncontrollable software with goals of being confident in ours and being consistent with long-term planning.

Considering the written above, we have to move onto another VM. We can either develop our own or stick with other Open Source solution, that is regularly updated and supported by maintainers, thus time-proven. Luckily, there are some VM's out there in public, suiting those requirements. On one hand, developing an in-house solution is better in terms of control, but we are not in the position to go this way, as nobody at ProximaX currently has enough expertise to implement custom VM for WASM. Even in the case where we acquire a capable cadre, the implementation would take lots of time anyway, thus picking an existing general-purpose WASM VM is more time effective. Another thing is the actual picking process, as we need to choose wisely, not to follow the same mistake we did while choosing the existing VM.

Nevertheless, after picking a new VM, we can not simply swap it with ours. Even though all such VMs out there, implement the same WASM format, the actual VMs will differ in various parts from the current one. From programming language, if our potential choice will be written in rust, for example - Wasmer, to simply noninteroperable WASM specs between current outdated VM and possible choice. Most importantly the provided APIs would differ drastically, as the VM we use only tried to become a general-purpose, but failed and just built to fulfill needs for the network of the original developers. These and other possibly unseen differences, again, will not allow us to simply switch to a new VM but will require an unpredictable amount of code rewrites and time respectively.

### Absence of Development Tooling/Libraries Design
DoD was never defined for SCs, but it is clearly seen that without proper tooling and libraries for SCs, they won't be useful for future developers.

A desirable set of tools from a developer perspective:
- IDE support
- Library/API for SC state management
- Library/API for Blockchain state access
- Library/API for inter contract communications
- DB library fo K/V
- In-home implementation for ERC-20 tokens and other popular smart contracts analogs over SCs
- Multiple examples of SCs showing rich feature set

There are also plenty of unresolved technical questions regarding the implementation of such libraries and APIs in the WASM ecosystem.

## Suggested Plan
// TODO