1.6 Success Criteria
Node Software / Protocol
Individual blocks
1
Blocks must refer to the previous block in the chain.
This prevents any user from being able to insert a block in-between two pre-existing blocks and is what forms the "chain" itself.
2
Blocks must be detected as invalid and disregarded by the node software.
If the node software cannot tell when a block is invalid, the whole system is effectively useless as if a bad actor manages to bypass the initial validation they could successfully hijack the whole system
3
Blocks must be detected as valid and approved by node software
If the node software mistakenly disproves of valid blocks they could punish good nodes/users, discouraging them from continued use of the system.
Network Communication
4
Nodes should have an open api server running using http that contains enough pathways to complete all the needed types of communication.
This is what allows nodes to communicate, which results in how the computations will be shared and how blocks will be updated to nodes around the blockchain
5
Node should have web-socket connection abilities for server or client connections.
This will allow 'private' nodes who do not have a public dns/ip address to connect to the network without having to set up a public address like is needed for a http server.
6
Nodes should be able to add and remove each other to their communication lists which should be stored locally
This prevents a node from having to rebuild it's network every time it connects to the network, and instead just connect to the nodes it already knows
7
Nodes should be able to store a local "grudge" object that just remembers who the node has a good or bad experience with to change their trust level when they create their next block.
This allows Node to remember who they've found trustworthy and who they shouldn't trust again so they can send things that require higher security (such as transaction initialisations) to more trustworthy nodes.
8
Nodes should send through a digital signature with each communication.
This ensures that each node knows who they're talking to and ensures that they don't hold a grudge against the wrong wallet.
9
Nodes should be able to remember each other through a combination of their wallet address and their ips/domains
This is so that when a node wants to communicate with a node running under a specific wallet they can communicate with the ips and domains they have associated with that node in the past instead of having to ask around other nodes until they find an active communicator to that wallet/node.
General features
10
A configuration handler
This allows for the loading and saving of node settings so that the node doesn't have to be setup up every time it launches.
11
The configuration handler should be usable and accessible to technical users with non-technical users being able to use it with additional help.
This ensures that technical users can custom the node software to work in any way in which they wish for it to work, with non-technical users being able to do the same if they really need to through the user of some external help or guides.
12
Nodes should have some kind of web based access dashboard.
This allows the user to see what their node is currently doing and interact with it directly.
13
The node dashboard should be easily accessible and usable by all forms of users.
This is the most basic side of the node software and it is essential that it is easily usable so that users of any type can understand whether their node is running and if so can interact with it as easily as possible.
Non-functional
The node software should not crash.
Since the idea of this software is that it should be setup, launched and then left alone for long periods of time whilst it completes calculations and transactions, hence a crash of the system could cause the software to be offline for long periods of time.
The software should be capable of receiving multiple messages per second.
This is such that the software is capable of handling multiple connections and sending data at a rate at which matches or exceeds the rate at which data is inputted into the system so as to prevent a backlog of requests from being formed.
The software should attempt to retry any failed processes (such as loading a file) and should only exit after multiple failed attempts.
Since certain processes are bound to fail occasionally, it is important that the node software re-attempts theses processes a few times to ensure it is not due to itself and is instead due to something outside of the softwares control (no internet, not setup properly, etc)
Webportal
Page types
A "home" page that summarises what the project is about.
Gives users a quick and brief explanation of what the project is so they can decide whether or not they want to continue using it.
An "info" page that explains the project in more detail.
This will give users a more detailed understanding of what is actually going on in the project and how it works, whilst attempting to solve any questions that may have been generated by the home page.
A "downloads" page that lets the user download the node software.
This is how users will get access to the node software and will help contribute to the network, thus is essential for increasing the ease of use of the project to a reasonable degree.
A "wallet" page that allows the user to see any data or items stored within their digital wallet.
This makes it much easier for casual users to see what they 'own' and thus interact with the network from a browser without having to download anything.
Non-functional
Non-technical users must be able to identify what the point of the project is just from the homepage of the website.
Users should be able to get to the majority of what they would want to get to within 3 clicks.
The easier it is for users to get to where they want to go, the more likely they are to do whatever they're trying to do.
The web-portal should be available and working on a variety of device sizes including mobile and desktop.
This allows users with any kind of internet enabled device to be able to use the site, as users tend to be distributed across different device types.
The web portal should run without crashing under any circumstance
Since the web portal will be a website and ran upon a public server, if it were to crash, a major stakeholder (the whole internet) would not be able to get access to the site.
Last updated