getStatus. Each client uses getStatus to request the status of the command execution until a majority of the replies contain the same hash. Specifically, this translates to the client staying in a loop until the getStatus method returns consensus on the hashes received. This method iterates through a list of the predefined cluster addresses and establishes a different, asynchronous web-socket connection with each of them, leveraging JavaScript’s native asynchronous capabilities. For each of these cluster nodes, the client sends the string with the contract name, command name, client id, the request id and the method name (getStatus). It then waits for the execution cluster’s replies and stores them in a map structure, where the key is the cluster address list index, and the value is the status received. Afterwards, in each of those asynchronous iterations, a new map structure is used to store the status received and how many times it was received. In addition, two variables store both the maximum counter and the respective status with the maximum counter. After all the asynchronous connections with all the execution cluster nodes are finalized, the client then checks for consensus: if the maximum counter registered is higher than half of the total nodes on that cluster, then there is consensus on that status. Provided that the status agreed on is a hash – since the command might have not been executed yet and the string ”pending” is returned in this case – then the client can request the command’s result. It might also happen that the majority of the requests are delayed. Thus, the client keeps track of the current request id and considers ”deprecated” any requests with a smaller id. Because the client collects the reply from a majority of the nodes that may execute their command, this serves as a group signature that guarantees that whatever reply is received is trustworthy.
