# Dependable and Secure Voting Mechanism in Edge Computing
## 3 System
### Architecture  
The system is composed of a set of distributed processes that run in edge and cloud nodes. Each edge node has a service that deals with edge device requests. The processes in the edge nodes have the objective of receiving the client requests, the responses from the cloud instances, as well as performing a voting mechanism with all its peers to validate the output from the cloud instances. In this architecture, there will also exist cloud services waiting for requests from the edge nodes. The cloud instances aim to receive the requests from the edge nodes, perform the computation from the request, produce a cryptographic digest from the output of the computation, and send the digest to the edge node. Each edge node is connected to a single cloud instance, and a single edge device sends the request to a set of edge nodes. From the client request, each edge node can identify each peer that the client also submits the request. All the entities in the system are connected by reliable channels, so no messages are lost, duplicated, or delivered out of order (e.g., TCP ). Data integrity and privacy are maintained through cryptographic hash functions (e.g., SHA-512 ) and public-key cryptography (e.g., TLS ). A cryptographic hash function is applied to the output of the computation performed in the cloud. To prevent any disclosure of the computation, only the produced message digest, or digest, is sent to the edge nodes. All messages that circulate between each party are encrypted with a session key to preventing eavesdropping and authenticated to guarantee that each party correctly belongs to the system. Figure 2 illustrates the multi-layer architecture composed by a cluster of edge nodes \(E\) (e.g., \(e_{0}\), \(e_{1}\), and \(e_{2}\)) that are in the same geographical region and are connected to a set of cloud instances \(C\) (e.g., \(c_{0}\), \(c_{1}\), and \(c_{2}\)) through the Internet Backbone. Contrary to the edge nodes, there is no requirement regarding the geographical distribution of cloud instances. When the client submits an operation \(\sigma\), the operation is replicated to the nearest cluster \(E\) and forwarded to \(C\). The result of the operation from each cloud \(V_{\sigma}\), which comes in the form of a message digest, \(H(V_{\sigma})\), is sent to \(E\) and validated by all \(e_{i}:i\in E\). It is assumed that \(V_{\sigma}\) is correct if \(E\) obtained at least \(f+1\) equal \(H(V_{\sigma})\). Our system is configured with parameter \(f\). In distributed systems, \(f\) is usually the maximum number of faulty results. Given an output \(v_{i}\in V_{\sigma}\), our system can tolerate not only \(f\) faults but also any number of faulty replicas as long as no more than \(f\) faulty replicas return the same wrong output. It includes the possibility that up to \(f\) replicas maliciously collude and the system remains able to reach a correct output. Consider a system of \(n\) edge nodes in an all-to-all message-passing network, \(n=2f+1\). Each edge node (\(e_{i}:i=\{0,1,...,n-1\}\)) is connected to a single cloud instance (\(c_{i}:i=\{0,1,...,n-1\}\)). Of these  
Figure 2: Edge network architecture with multiple cloud instances. \(2n\) nodes, which includes \(n\) edge nodes and \(n\) cloud instances, our system is correct if the edge nodes can still vote for the correct value \(v\) whether there are \(f\) faulty edge nodes, \(f\) faulty cloud instances, or any combination of both. Initially, this solution seems expensive in terms of the number of resources needed. Each cloud instance is a set of several nodes with the goal to execute computer-intensive operations. The edge nodes are responsible for the voting mechanism operation, leaving the computation of complex operations to the cloud instances. While we use \(2f+1\) cloud instances with variable size to get the benefits of using a multi-cloud environment, it is necessary to add the \(2f+1\) edge nodes to this solution.