Codi

codi

Privacy in Cloud Computing through Immersion-based Coding: Conclusion and References

Authors:
(1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands;
(2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands;
(3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Table of Links Abstract and Introduction Problem Formulation Affine Solution to Problem 1 Privacy Guarantee General Guidelines for Implementation Case Studies Conclusion and References VI. CASE STUDIES In this section, we show the performance of the immersion-based coding algorithm on two use cases – privacy in optimization/learning algorithms and privacy in a nonlinear networked control system. A. Immersion-based Coding for Privacy in Optimization/Learning algorithms Machine learning (ML) has been successfully used in a wide variety of applications for multiple fields and industries. However, gathering extensive amounts of training data poses a challenge for ML systems. Commonly, increased data leads to improved ML model performance, necessitating the need for large datasets often sourced from various origins. Nonetheless, the process of gathering and using such data, along with developing ML models, presents significant privacy risks due to the potential exposure of private information. In recent years, various privacy-preserving schemes have been implemented to address the privacy leakage in ML. Most of them rely on cryptography-based techniques such as Secure Multiparty Computation (SMC) [40] and Homomorphic Encryption (HE) [41], and perturbation-based techniques such as Differential Privacy (DP) [42]. Although current solutions improve privacy of ML algorithms, they often do this at the expense of model performance and system efficiency. In this paper, we propose a privacy-preserving machine learning framework through the immersion-based coding algorithm. The main idea is to treat the optimization algorithm employed in the standard ML process as a dynamical system that we seek to immerse into a higher-dimensional system. We have explored the use of preliminary version of the ideas on this paper for privacy in federated learning with Stochastic Gradient Descent (SGD) as the optimization algorithm [26]. In this work, we generalize these results and implement immersion-based coding to encode all types of gradient descent optimization algorithms and employ the encoded optimizers to train machine-learning models. Stochastic Gradient Descent (SGD) is one of the most common gradient descent optimization techniques in machine learning [43]. For SGD, function p(·, ·) can be written as follows: 2) Immersion-based Coding for Privacy-Preserving Gradient Descent Optimizers: In this section, we encode the gradient descent optimization algorithm given in (38), following the same technique that we discussed in Corollary 1, which is the immersion-based coding for remote dynamical algorithms with different time scales. The encoded optimization algorithm can be employed to provide privacy for the database and model in machine learning algorithms. In this application, the optimizer in (38) is the original dynamical system Σ in (19) that we want to immerse to provide privacy. We consider a setting where the user who owns the database uploads the complete database D to the cloud, where the training process is executed by running the gradient-based optimizer (38). The optimizer iterates T times in the cloud to converge to a local optimum. Subsequently, the optimal model parameters vector w ∗ is sent back to the user. Since the user and cloud send the database and optimal model, which play the role of input and utility of the algorithm, only once, the number of user iterations is K = 1, and the number of local iterations is T. Functions f(·) and g(·) in (19) can be modeled as wt+1 = f(wt, D) := wt − p(wt, D) and w ∗ = g(wT ) := wT in this case. The model parameters wt, database D, and the optimal model parameters vector w ∗ can be considered as the internal variables ζt, input y, and utility u of the original algorithm Σ in (19). The immersion and utility encoding maps are given by: the target gradient descent optimizer is given by: and the inverse function: This approach can be employed to encode all kinds of gradient descent optimization algorithms that are typically used by machine learning algorithms. We will refer to machine learning algorithms that utilize immersion-based coding to preserve privacy as System Immersion-based Machine Learning (SIML). 3) Case Study of Optimization/Learning algorithms: In this section, we implement our proposed SIML scheme for performance evaluation using a multi-layer perception (MLP) [44] and a real-world machine learning database. Our investigation involves utilizing two optimization tools, i.e., Adam and SGD, on the MNIST database [45]. The experimental details are described as follows: • Dataset: We test our algorithm on the standard MNIST database for handwritten digit recognition, containing 60000 training and 10000 testing instances of 28× 28 size gray-level images, which are flattened to the vectors of dimension 784. • Model: The MLP model is a feed-forward deep neural network with ReLU units and a softmax layer of 10 classes (corresponding to the ten digits) with two hidden layers containing 256 hidden units and cross-entropy loss. The MLP model contains 269,322 parameters. • Optimization tools: As optimization algorithms, the SGD and Adam optimizers with learning rate 0.001 and T = 50 epochs are employed to train ML models. Our implementation uses Keras with a Tensorflow backend. First, in Fig. 2, we show the impact of the proposed coding mechanisms by comparing one sample of the original MNIST dataset and its encoded format. As can be seen in this figure, the encoded image closely resembles the random term in the distorting mechanism, differing significantly from the original image. Therefore, adversaries can not infer any information from the original image by accessing the encoded one. Then, the comparison between training accuracy and loss outcomes of the SIML and standard ML frameworks is illustrated in Fig. 3. In our implementation, the SIML framework utilizes target SGD and target Adam optimizers with the distorted MNIST database, while the traditional ML framework employs original SGD and Adam optimizers with the original MNIST dataset. It’s evident that the accuracy and loss metrics under the SIML configuration are similar to those in the non-privacy setting, indicating that SIML can incorporate cryptographic methods into ML systems without compromising model accuracy and convergence rate. B. Privacy-aware Networked Control We illustrate the performance of the immersion-based coding for networked control systems through a case study of a two-stage chemical reactor with delayed recycle streams. The authors in [46] propose an adaptive output feedback controller for this chemical reactor dynamics. We assume the controller is run in the cloud and aim to run it in a private manner using the proposed coding scheme. Consider the dynamic model of the reactor (as reported in [46]): We use the following adaptive output feedback controller (see [46] for details) in order to achieve global adaptive stabilization of system (45): We consider the setting where the controller (47), (48) is run in the cloud. We employ the proposed immersion-based coding in Proposition 1 to enable a secure networked control system. The controller (47) can be reformulated in a compact form as follows. The encoding and immersion maps are given by: the target controller is given by: and the inverse function: This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Authors: Authors: (1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Table of Links Abstract and Introduction Abstract and Introduction Problem Formulation Problem Formulation Affine Solution to Problem 1 Affine Solution to Problem 1 Privacy Guarantee Privacy Guarantee General Guidelines for Implementation General Guidelines for Implementation Case Studies Case Studies Conclusion and References Conclusion and References VI. CASE STUDIES In this section, we show the performance of the immersion-based coding algorithm on two use cases – privacy in optimization/learning algorithms and privacy in a nonlinear networked control system. A. Immersion-based Coding for Privacy in Optimization/Learning algorithms A. Immersion-based Coding for Privacy in Optimization/Learning algorithms Machine learning (ML) has been successfully used in a wide variety of applications for multiple fields and industries. However, gathering extensive amounts of training data poses a challenge for ML systems. Commonly, increased data leads to improved ML model performance, necessitating the need for large datasets often sourced from various origins. Nonetheless, the process of gathering and using such data, along with developing ML models, presents significant privacy risks due to the potential exposure of private information. In recent years, various privacy-preserving schemes have been implemented to address the privacy leakage in ML. Most of them rely on cryptography-based techniques such as Secure Multiparty Computation (SMC) [40] and Homomorphic Encryption (HE) [41], and perturbation-based techniques such as Differential Privacy (DP) [42]. Although current solutions improve privacy of ML algorithms, they often do this at the expense of model performance and system efficiency. In this paper, we propose a privacy-preserving machine learning framework through the immersion-based coding algorithm. The main idea is to treat the optimization algorithm employed in the standard ML process as a dynamical system that we seek to immerse into a higher-dimensional system. We have explored the use of preliminary version of the ideas on this paper for privacy in federated learning with Stochastic Gradient Descent (SGD) as the optimization algorithm [26]. In this work, we generalize these results and implement immersion-based coding to encode all types of gradient descent optimization algorithms and employ the encoded optimizers to train machine-learning models. Stochastic Gradient Descent (SGD) is one of the most common gradient descent optimization techniques in machine learning [43]. For SGD, function p(·, ·) can be written as follows: 2) Immersion-based Coding for Privacy-Preserving Gradient Descent Optimizers: In this section, we encode the gradient descent optimization algorithm given in (38), following the same technique that we discussed in Corollary 1, which is the immersion-based coding for remote dynamical algorithms with different time scales. The encoded optimization algorithm can be employed to provide privacy for the database and model in machine learning algorithms. 2) Immersion-based Coding for Privacy-Preserving Gradient Descent Optimizers: In this application, the optimizer in (38) is the original dynamical system Σ in (19) that we want to immerse to provide privacy. We consider a setting where the user who owns the database uploads the complete database D to the cloud, where the training process is executed by running the gradient-based optimizer (38). The optimizer iterates T times in the cloud to converge to a local optimum. Subsequently, the optimal model parameters vector w ∗ is sent back to the user. Since the user and cloud send the database and optimal model, which play the role of input and utility of the algorithm, only once, the number of user iterations is K = 1, and the number of local iterations is T. Functions f(·) and g(·) in (19) can be modeled as wt+1 = f(wt, D) := wt − p(wt, D) and w ∗ = g(wT ) := wT in this case. The model parameters wt, database D, and the optimal model parameters vector w ∗ can be considered as the internal variables ζt, input y, and utility u of the original algorithm Σ in (19). The immersion and utility encoding maps are given by: the target gradient descent optimizer is given by: and the inverse function: This approach can be employed to encode all kinds of gradient descent optimization algorithms that are typically used by machine learning algorithms. We will refer to machine learning algorithms that utilize immersion-based coding to preserve privacy as System Immersion-based Machine Learning (SIML). 3) Case Study of Optimization/Learning algorithms: In this section, we implement our proposed SIML scheme for performance evaluation using a multi-layer perception (MLP) [44] and a real-world machine learning database. Our investigation involves utilizing two optimization tools, i.e., Adam and SGD, on the MNIST database [45]. The experimental details are described as follows: 3) Case Study of Optimization/Learning algorithms: • Dataset: We test our algorithm on the standard MNIST database for handwritten digit recognition, containing 60000 training and 10000 testing instances of 28× 28 size gray-level images, which are flattened to the vectors of dimension 784. • Model: The MLP model is a feed-forward deep neural network with ReLU units and a softmax layer of 10 classes (corresponding to the ten digits) with two hidden layers containing 256 hidden units and cross-entropy loss. The MLP model contains 269,322 parameters. • Optimization tools: As optimization algorithms, the SGD and Adam optimizers with learning rate 0.001 and T = 50 epochs are employed to train ML models. Our implementation uses Keras with a Tensorflow backend. First, in Fig. 2, we show the impact of the proposed coding mechanisms by comparing one sample of the original MNIST dataset and its encoded format. As can be seen in this figure, the encoded image closely resembles the random term in the distorting mechanism, differing significantly from the original image. Therefore, adversaries can not infer any information from the original image by accessing the encoded one. Then, the comparison between training accuracy and loss outcomes of the SIML and standard ML frameworks is illustrated in Fig. 3. In our implementation, the SIML framework utilizes target SGD and target Adam optimizers with the distorted MNIST database, while the traditional ML framework employs original SGD and Adam optimizers with the original MNIST dataset. It’s evident that the accuracy and loss metrics under the SIML configuration are similar to those in the non-privacy setting, indicating that SIML can incorporate cryptographic methods into ML systems without compromising model accuracy and convergence rate. B. Privacy-aware Networked Control B. Privacy-aware Networked Control We illustrate the performance of the immersion-based coding for networked control systems through a case study of a two-stage chemical reactor with delayed recycle streams. The authors in [46] propose an adaptive output feedback controller for this chemical reactor dynamics. We assume the controller is run in the cloud and aim to run it in a private manner using the proposed coding scheme. Consider the dynamic model of the reactor (as reported in [46]): We use the following adaptive output feedback controller (see [46] for details) in order to achieve global adaptive stabilization of system (45): We consider the setting where the controller (47), (48) is run in the cloud. We employ the proposed immersion-based coding in Proposition 1 to enable a secure networked control system. The controller (47) can be reformulated in a compact form as follows. The encoding and immersion maps are given by: the target controller is given by: and the inverse function: This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Privacy in Cloud Computing through Immersion-based Coding: Case Studies

Authors:
(1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands;
(2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands;
(3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Table of Links Abstract and Introduction Problem Formulation Affine Solution to Problem 1 Privacy Guarantee General Guidelines for Implementation Case Studies Conclusion and References IV. PRIVACY GUARANTEES A privacy-level analysis of random affine maps of the form (7) has been discussed in the literature, see [33] (cryptanalysis) and [34] (DP). However, the guarantees they show are for square and invertible encoding matrices. In our scheme, we cannot directly apply those results as our encoding matrices (Π1 and Π3) are rectangular (tall matrices). We need rectangular matrices to be able to exploit their kernels to remove the injected distortion at the user side. A complication with this architecture is that the covariance matrix of N1sk (which is part of the user data encoding mechanism) is degenerate regardless of the probability distribution of sk. The latter prevents us from using off-the-shelf tools to design the affine maps to guarantee differential privacy. In what follows, we provide a tailored solution to guarantee DP for the class of mechanisms that we consider. In particular, we prove that the proposed scheme, with full-column rank encoding matrices, can provide any desired level of differential privacy without reducing the accuracy and performance of the original algorithm. A. Differential Privacy Definition 1 [Adjacency] Let X denote the space of all possible datasets. We say that D ∈ X and D′ ∈ X are adjacent if they differ on a single element. Definition 2 [(ϵ, δ)-Differential Privacy [35]] The random mechanism M : X → R with domain X and range R is said to provide (ϵ, δ)-differential privacy, if for any two adjacent datasets D, D′ ∈ X and for all measurable sets S ⊆ R: If δ = 0, M is said to satisfy ϵ-differential privacy. From Definition 2, we have that a mechanism provides DP if its probability distribution satisfies (25) for some ϵ and δ. Then, if we seek to design the mechanism to guarantee DP, we need to shape its probability distribution. This is usually done by injecting noise into the data we seek to encode. The noise statistics must be designed in terms of the sensitivity of the data to be encoded. Sensitivity refers to the maximum change of the data due to the difference in a single element of the dataset. Definition 3 (Sensitivity) : Given two adjacent datasets D, D′ ∈ X , and a query function q : X → R (a deterministic function of datasets). The sensitivity of q(·) is formulated as A differential privacy mechanism M based on the sensitivity (26) needs to be designed so that the differential privacy condition (25) holds. B. Immersion-based Coding Differential Privacy Guarantee Solution to Problem 3 where (a) follows from the following triangle inequality Due to the sensitivity relation (28), we have Hence, inequality (30) implies C. Perfect Security A perfectly secure cryptosystem is a secure system against adversaries with unlimited computing resources and time, see [36]. In [37], Shannon proves that a necessary condition encryption method to be perfectly secure is that the uncertainty of the secret key is larger than or equal to the uncertainty of the plaintext, see [38]. He proposes a one-time pad encryption scheme in which the key is randomly selected and never used again. The one-time pad gives unbounded entropy of the key space, i.e., infinite key space, which provides perfect security. Perfect secrecy is lost when the key is not random or if it is reused. This perfect security idea can be used to assess the performance of our proposed coding mechanism. Given the fact that in the proposed mechanism, (7), the encoding keys, (Π1, sk) and (Π3, Π4N1sk), are random, change in every iteration, and provide an infinite-dimensional key space (the support of sk), can be considered perfectly secure. Perfect secrecy of the proposed coding mechanisms can also be concluded from the differential privacy point of view. In [39], the authors define perfect secrecy in terms of DP. They state that a mechanism M : X → R, with domain X and range R is perfectly secret if for any two adjacent D, D′ ∈ X and for all measurable sets S ⊆ R. Then, the output of the mechanism reveals no information about private data. Comparing the definition of perfect secrecy in (37) and the definition of differential privacy (Definition 2), we can conclude that a differentially private mechanism is perfectly secret if (ϵ, δ) equal zero. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Authors: Authors: (1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Table of Links Abstract and Introduction Abstract and Introduction Problem Formulation Problem Formulation Affine Solution to Problem 1 Affine Solution to Problem 1 Privacy Guarantee Privacy Guarantee General Guidelines for Implementation General Guidelines for Implementation Case Studies Case Studies Conclusion and References Conclusion and References IV. PRIVACY GUARANTEES A privacy-level analysis of random affine maps of the form (7) has been discussed in the literature, see [33] (cryptanalysis) and [34] (DP). However, the guarantees they show are for square and invertible encoding matrices. In our scheme, we cannot directly apply those results as our encoding matrices (Π1 and Π3) are rectangular (tall matrices). We need rectangular matrices to be able to exploit their kernels to remove the injected distortion at the user side. A complication with this architecture is that the covariance matrix of N1sk (which is part of the user data encoding mechanism) is degenerate regardless of the probability distribution of sk. The latter prevents us from using off-the-shelf tools to design the affine maps to guarantee differential privacy. In what follows, we provide a tailored solution to guarantee DP for the class of mechanisms that we consider. In particular, we prove that the proposed scheme, with full-column rank encoding matrices, can provide any desired level of differential privacy without reducing the accuracy and performance of the original algorithm. A. Differential Privacy A. Differential Privacy Definition 1 [Adjacency] Let X denote the space of all possible datasets. We say that D ∈ X and D′ ∈ X are adjacent if they differ on a single element. Definition 1 [Adjacency] Let X denote the space of all possible datasets. We say that D ∈ X and D′ ∈ X are adjacent if they differ on a single element. Definition 2 [(ϵ, δ)-Differential Privacy [35]] The random mechanism M : X → R with domain X and range R is said to provide (ϵ, δ)-differential privacy, if for any two adjacent datasets D, D′ ∈ X and for all measurable sets S ⊆ R: Definition 2 [(ϵ, δ)-Differential Privacy [35]] The random mechanism M : X → R with domain X and range R is said to provide (ϵ, δ)-differential privacy, if for any two adjacent datasets D, D′ ∈ X and for all measurable sets S ⊆ R: If δ = 0, M is said to satisfy ϵ-differential privacy. From Definition 2, we have that a mechanism provides DP if its probability distribution satisfies (25) for some ϵ and δ. Then, if we seek to design the mechanism to guarantee DP, we need to shape its probability distribution. This is usually done by injecting noise into the data we seek to encode. The noise statistics must be designed in terms of the sensitivity of the data to be encoded. Sensitivity refers to the maximum change of the data due to the difference in a single element of the dataset. Definition 3 (Sensitivity) : Given two adjacent datasets D, D′ ∈ X , and a query function q : X → R (a deterministic function of datasets). The sensitivity of q(·) is formulated as Definition 3 (Sensitivity) : Given two adjacent datasets D, D′ ∈ X , and a query function q : X → R (a deterministic function of datasets). The sensitivity of q(·) is formulated as A differential privacy mechanism M based on the sensitivity (26) needs to be designed so that the differential privacy condition (25) holds. B. Immersion-based Coding Differential Privacy Guarantee B. Immersion-based Coding Differential Privacy Guarantee Solution to Problem 3 Solution to Problem 3 where (a) follows from the following triangle inequality Due to the sensitivity relation (28), we have Hence, inequality (30) implies C. Perfect Security C. Perfect Security A perfectly secure cryptosystem is a secure system against adversaries with unlimited computing resources and time, see [36]. In [37], Shannon proves that a necessary condition encryption method to be perfectly secure is that the uncertainty of the secret key is larger than or equal to the uncertainty of the plaintext, see [38]. He proposes a one-time pad encryption scheme in which the key is randomly selected and never used again. The one-time pad gives unbounded entropy of the key space, i.e., infinite key space, which provides perfect security. Perfect secrecy is lost when the key is not random or if it is reused. This perfect security idea can be used to assess the performance of our proposed coding mechanism. Given the fact that in the proposed mechanism, (7), the encoding keys, (Π1, sk) and (Π3, Π4N1sk), are random, change in every iteration, and provide an infinite-dimensional key space (the support of sk), can be considered perfectly secure. Perfect secrecy of the proposed coding mechanisms can also be concluded from the differential privacy point of view. In [39], the authors define perfect secrecy in terms of DP. They state that a mechanism M : X → R, with domain X and range R is perfectly secret if for any two adjacent D, D′ ∈ X and for all measurable sets S ⊆ R. Then, the output of the mechanism reveals no information about private data. Comparing the definition of perfect secrecy in (37) and the definition of differential privacy (Definition 2), we can conclude that a differentially private mechanism is perfectly secret if (ϵ, δ) equal zero. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Privacy in Cloud Computing through Immersion-based Coding: Privacy Guarantee

Authors:
(1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands;
(2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands;
(3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Table of Links Abstract and Introduction Problem Formulation Affine Solution to Problem 1 Privacy Guarantee General Guidelines for Implementation Case Studies Conclusion and References III. AFFINE SOLUTION TO PROBLEM 1 In this section, we construct a prescriptive solution to Problem 1 using random affine maps. Let the user data encoding map π1(·), the immersion map π2(·), and the utility map π3(·) be affine functions of the form: We can now state the proposed solution to Problem 1 Proof: Proposition 1 follows from the discussion provided in the solution section above, Section II Remark 2 In Proposition 1, we present the first part of the design of the proposed immersion-based coding mechanism for privacy. Note that the proposed scheme is independent of the nature of the user data yk and utility uk, and does not require any assumption on the original algorithm. These features make the proposed scheme suitable to enforce privacy for a large class of linear and nonlinear high-dimensional algorithms. Remark 3 This manuscript primarily focuses on immersionbased coding for privacy of discrete-time algorithms operating in the cloud. It is noteworthy that it can be proved that the application of the proposed coding and target algorithm in Proposition 1 can be extended for privacy of continuous-time systems. This extension highlights the wider application of the immersion-based coding, providing a solution for cloud-based privacy covering discrete and continuous-time algorithms. A. Algorithms with Different Time-Scale The class of algorithms considered in (1), and the results that followed, operates on a single time scale. That is, the algorithm reacts to the received yk, iterates once according to f(·) and g(·), and sends the utility uk back to the user. This is repeated sequentially between the user and the cloud. Algorithms that fit this class are, e.g., control, monitoring, and federated learning schemes. Note, however, that there are many algorithms that operate on a different time scale from that of the user. That is, there are algorithms that receive the user data yk at time k, iterate locally multiple times in the cloud (say for t = 1, . . . , T), and only after a number of local iterations (T), the data utility uk is sent back to the user. Algorithms that fit this class are, for instance, general learning algorithms where it is often the case that the complete data set is uploaded to the cloud, the training is done there by running gradient-like steps multiple times, and only when the cost function has decreased to an acceptable level, the final trained model is sent back to the use For the sake of completeness, we concisely provide the corresponding coding result for algorithms with different time scales. Consider discrete-time dynamic algorithms of the for Further, consider the corresponding higher-dimensional target algorithm: Following the reasoning described in the above section, for algorithm (19) and corresponding target algorithm (20), we let the user data encoding map, the immersion map, and the utility map be affine functions of the form: Problem 2 is an analogue to Problem 1 for systems with two time scales. Following the lines of the solution to Problem 1, we provide a solution to Problem 2 in the following corollary of Proposition 1. Proof: The proof of Corollary 1 follows the same lines as the proof of Proposition 1. Only the time scales of the encoded signals change. The proof is omitted here for the sake of brevity. So far, we have presented the proposed immersion-based coding for two classes of discrete-time algorithms built around stochastic affine maps. Note that the only constraint on these maps is that they are full-rank. In the next section, we state sufficient conditions for the proposed privacy scheme to guarantee a prescribed level of differential privacy. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Authors: Authors: (1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Table of Links Abstract and Introduction Abstract and Introduction Problem Formulation Problem Formulation Affine Solution to Problem 1 Affine Solution to Problem 1 Privacy Guarantee Privacy Guarantee General Guidelines for Implementation General Guidelines for Implementation Case Studies Case Studies Conclusion and References Conclusion and References III. AFFINE SOLUTION TO PROBLEM 1 In this section, we construct a prescriptive solution to Problem 1 using random affine maps. Let the user data encoding map π1(·), the immersion map π2(·), and the utility map π3(·) be affine functions of the form: We can now state the proposed solution to Problem 1 Proof : Proposition 1 follows from the discussion provided in the solution section above, Section II Proof Proof Remark 2 In Proposition 1, we present the first part of the design of the proposed immersion-based coding mechanism for privacy. Note that the proposed scheme is independent of the nature of the user data yk and utility uk, and does not require any assumption on the original algorithm. These features make the proposed scheme suitable to enforce privacy for a large class of linear and nonlinear high-dimensional algorithms. Remark 2 In Proposition 1, we present the first part of the design of the proposed immersion-based coding mechanism for privacy. Note that the proposed scheme is independent of the nature of the user data yk and utility uk, and does not require any assumption on the original algorithm. These features make the proposed scheme suitable to enforce privacy for a large class of linear and nonlinear high-dimensional algorithms. Remark 3 This manuscript primarily focuses on immersionbased coding for privacy of discrete-time algorithms operating in the cloud. It is noteworthy that it can be proved that the application of the proposed coding and target algorithm in Proposition 1 can be extended for privacy of continuous-time systems. This extension highlights the wider application of the immersion-based coding, providing a solution for cloud-based privacy covering discrete and continuous-time algorithms. Remark 3 This manuscript primarily focuses on immersionbased coding for privacy of discrete-time algorithms operating in the cloud. It is noteworthy that it can be proved that the application of the proposed coding and target algorithm in Proposition 1 can be extended for privacy of continuous-time systems. This extension highlights the wider application of the immersion-based coding, providing a solution for cloud-based privacy covering discrete and continuous-time algorithms. A. Algorithms with Different Time-Scale A. Algorithms with Different Time-Scale The class of algorithms considered in (1), and the results that followed, operates on a single time scale. That is, the algorithm reacts to the received yk, iterates once according to f(·) and g(·), and sends the utility uk back to the user. This is repeated sequentially between the user and the cloud. Algorithms that fit this class are, e.g., control, monitoring, and federated learning schemes. Note, however, that there are many algorithms that operate on a different time scale from that of the user. That is, there are algorithms that receive the user data yk at time k, iterate locally multiple times in the cloud (say for t = 1, . . . , T), and only after a number of local iterations (T), the data utility uk is sent back to the user. Algorithms that fit this class are, for instance, general learning algorithms where it is often the case that the complete data set is uploaded to the cloud, the training is done there by running gradient-like steps multiple times, and only when the cost function has decreased to an acceptable level, the final trained model is sent back to the use For the sake of completeness, we concisely provide the corresponding coding result for algorithms with different time scales. Consider discrete-time dynamic algorithms of the for Further, consider the corresponding higher-dimensional target algorithm: Following the reasoning described in the above section, for algorithm (19) and corresponding target algorithm (20), we let the user data encoding map, the immersion map, and the utility map be affine functions of the form: Problem 2 is an analogue to Problem 1 for systems with two time scales. Following the lines of the solution to Problem 1, we provide a solution to Problem 2 in the following corollary of Proposition 1. Proof : The proof of Corollary 1 follows the same lines as the proof of Proposition 1. Only the time scales of the encoded signals change. The proof is omitted here for the sake of brevity. Proof Proof So far, we have presented the proposed immersion-based coding for two classes of discrete-time algorithms built around stochastic affine maps. Note that the only constraint on these maps is that they are full-rank. In the next section, we state sufficient conditions for the proposed privacy scheme to guarantee a prescribed level of differential privacy. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Privacy in Cloud Computing through Immersion-based Coding: Affine Solution to Problem 1

Authors:
(1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands;
(2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands;
(3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Table of Links Abstract and Introduction Problem Formulation Affine Solution to Problem 1 Privacy Guarantee General Guidelines for Implementation Case Studies Conclusion and References II. PROBLEM FORMULATION The setting that we consider is the following. The user aims to run an algorithm remotely (in the cloud) using her/his local data yk to produce some data utility uk (what the algorithm returns), see Fig. 1(a). However, the user does not want to share the original data yk as it contains sensitive private information that could be inferred. The goal of our proposed privacy-preserving scheme is to devise an encoding mechanism to mask the original data and the algorithm to be run in the cloud so that inference of sensitive information from the encoded disclosed data is as hard as possible (in a probabilistic Differential-Privacy (DP) sense) without degrading the performance of the encoded algorithm (so a homomorphic probabilistic scheme). A. Immersion-based Coding We now have all the ingredients to pose the problem we seek to address. The flowchart of the original algorithm and the target algorithm are shown in Fig. 1. Remark 1 Note that solutions to Problem 1 characterize a class of encoding maps and target algorithms for which we can design homomorphic encryption schemes (a prescriptive design, i.e., for given (f, g, ζ0)) that operate over the reals. However, this class is infinite-dimensional (over a function space). It leads to an underdetermined algebraic problem with an infinite dimensional solution space. To address this aspect of the problem, we impose structure on the maps we seek to design. We restrict to random affine maps composed of linear coordinate transformations and additive random processes. In what follows, we prove that this class of maps is sufficient to guarantee an arbitrary level of differential privacy. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Authors: Authors: (1) Haleh Hayati, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (2) Nathan van de Wouw, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands; (3) Carlos Murguia, Department of Mechanical Engineering, Dynamics and Control Group, Eindhoven University of Technology, The Netherlands, and with the School of Electrical Engineering and Robotics, Queensland University of Technology, Brisbane, Australia. Table of Links Abstract and Introduction Abstract and Introduction Problem Formulation Problem Formulation Affine Solution to Problem 1 Affine Solution to Problem 1 Privacy Guarantee Privacy Guarantee General Guidelines for Implementation General Guidelines for Implementation Case Studies Case Studies Conclusion and References Conclusion and References II. PROBLEM FORMULATION The setting that we consider is the following. The user aims to run an algorithm remotely (in the cloud) using her/his local data yk to produce some data utility uk (what the algorithm returns), see Fig. 1(a). However, the user does not want to share the original data yk as it contains sensitive private information that could be inferred. The goal of our proposed privacy-preserving scheme is to devise an encoding mechanism to mask the original data and the algorithm to be run in the cloud so that inference of sensitive information from the encoded disclosed data is as hard as possible (in a probabilistic Differential-Privacy (DP) sense) without degrading the performance of the encoded algorithm (so a homomorphic probabilistic scheme). A. Immersion-based Coding A. Immersion-based Coding We now have all the ingredients to pose the problem we seek to address. The flowchart of the original algorithm and the target algorithm are shown in Fig. 1. Remark 1 Note that solutions to Problem 1 characterize a class of encoding maps and target algorithms for which we can design homomorphic encryption schemes (a prescriptive design, i.e., for given (f, g, ζ0)) that operate over the reals. However, this class is infinite-dimensional (over a function space). It leads to an underdetermined algebraic problem with an infinite dimensional solution space. To address this aspect of the problem, we impose structure on the maps we seek to design. We restrict to random affine maps composed of linear coordinate transformations and additive random processes. In what follows, we prove that this class of maps is sufficient to guarantee an arbitrary level of differential privacy. Remark 1 Note that solutions to Problem 1 characterize a class of encoding maps and target algorithms for which we can design homomorphic encryption schemes (a prescriptive design, i.e., for given (f, g, ζ0)) that operate over the reals. However, this class is infinite-dimensional (over a function space). It leads to an underdetermined algebraic problem with an infinite dimensional solution space. To address this aspect of the problem, we impose structure on the maps we seek to design. We restrict to random affine maps composed of linear coordinate transformations and additive random processes. In what follows, we prove that this class of maps is sufficient to guarantee an arbitrary level of differential privacy. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Privacy in Cloud Computing through Immersion-based Coding: Problem Formulation

Privacy in Cloud Computing through Immersion-based Coding: Abstract and Introduction

On March 2nd, 2023, we launched a simple VS Code extension to help developers search their codebases. Fast forward a few weeks and we had over 7,000 users – we had volumes of traffic that were far more than we could afford or handle. This is the inside story of how we navigated that chaos, completely rebuilt our architecture, and learned some hard lessons about building AI-powered developer tools. Things that don’t scale We were a small team of three, fresh out of Y Combinator's Winter 2023 batch, with a product that was very much in the "do things that don't scale" phase. Our core functionality allowed developers to "search for what your code does, not what it is," – enabling queries like "Find where we initialize Stripe in React and add some logging." Our approach was simple but computationally intensive. We indexed entire codebases, passing each snippet through an LLM to generate a description, which we then embedded. It was a success, giving us the "what the code does" functionality, but at a significant cost. Our launch tweet unexpectedly took off, and signups started pouring in. While this was exciting, it quickly became apparent that our backend architecture wasn't prepared for this level of demand. Worse, our approach was incredibly inefficient and expensive at scale. At our peak, we were processing nearly a quarter of a billion tokens per day. This was both a technical challenge and a financial nightmare. We were burning through thousands of dollars worth of tokens and constantly hitting our rate limits. Hard…but productive decisions One of our YC group partners, Tom Blomfield, gave us crucial advice: stop onboarding customers who were going to have a bad experience. It was tough to turn away potential users, but we knew that short-term disappointment would protect both parties from damage in the long term. We found ourselves at a bit of a crossroads. Suddenly our minimum viable product had lost the “viable” bit. We needed to figure out a way to deliver the same functionality without relying on an LLM for every query. We considered using a self-hosted LLM as an alternative, but the costs would still have been prohibitively high for our traffic levels. After a deeper analysis, we realized that having an LLM in the loop simply wasn't feasible with current technology. This led us to a solution that, while not groundbreaking, is often overlooked: creating a custom matrix to bias embeddings for our specific use case. Think of this as reorganising cookbooks based on how chefs actually search for recipes (e.g. cuisine or ingredients), rather than using a standard alphabetical system. This tailored approach helps find the right recipe much faster and more accurately, just as the custom matrix improves matching code snippets to user queries. We gathered a corpus of open-source code snippets from GitHub and used an LLM to generate synthetic user queries for each snippet. We then trained a model to optimize the embeddings for our particular domain. The results were impressive. Our accuracy jumped from 61% to around 90%, all without the need for constant LLM queries. This allowed us to maintain the core functionality of our product while drastically reducing costs and computational overhead. Our approach to data curation became increasingly sophisticated, and we developed a proprietary pipeline to generate datasets that truly capture the nuances of how human developers work. What we learned Be prepared to pivot: Our initial approach seemed promising, but it didn't hold up under real-world conditions. Being willing to completely rethink our architecture was what allowed us to survive.
Monitor aggressively: We were caught off guard by the sudden surge in usage. Implementing better monitoring and alerting systems could have helped us respond more quickly.
Understand your cost structure: We didn't fully grasp how our costs would scale with usage. This led to some painful financial realisations in those early days.
Communicate clearly with users: Managing expectations during our rebuilding phase was challenging. We learned the importance of transparent communication, especially when dealing with technical users.
Don't underestimate data quality: In rebuilding our system, we found that carefully curated, high-quality data was far more valuable than simply having more data. The road to Genie & the OpenAI validation Our journey from a simple VS Code extension to Genie was marked by constant iteration and a willingness to pivot. We built what we could while waiting for AI technology to catch up to our vision. Our initial code search and retrieval system, cloud-based indexing platform, and experiments with emerging AI models all became crucial building blocks. When more advanced language models finally became available, we were uniquely positioned to integrate them with our existing tools, leading to the development of Genie - a fully autonomous AI software engineer that embodies our original vision. By October 2023, we had developed a proprietary technique to generate datasets that truly captured the nuances of how human developers work. This caught the attention of OpenAI, who granted us what was at the time rare early access to fine-tune GPT-4 beyond public availability. This collaboration allowed us to push the boundaries of what was possible with our approach, and in August 2024, we achieved a major milestone. Genie scored 43.8% on the industry-standard SWE-Bench Verified, significantly outperforming previous records held by major tech companies. Our product nearly broke under its own success. But we're now excited about the potential to transform how developers work. The bottom line is that the unprepared, underestimated success of a first product can derail a company, but it can also set it on a path to something a lot more meaningful than the founders initially imagined - if they  have the humility to challenge their own assumptions, like we did. On March 2nd, 2023, we launched a simple VS Code extension to help developers search their codebases. Fast forward a few weeks and we had over 7,000 users – we had volumes of traffic that were far more than we could afford or handle. This is the inside story of how we navigated that chaos, completely rebuilt our architecture, and learned some hard lessons about building AI-powered developer tools. Things that don’t scale We were a small team of three, fresh out of Y Combinator's Winter 2023 batch, with a product that was very much in the "do things that don't scale" phase. Our core functionality allowed developers to "search for what your code does, not what it is," – enabling queries like "Find where we initialize Stripe in React and add some logging." Our approach was simple but computationally intensive. We indexed entire codebases, passing each snippet through an LLM to generate a description, which we then embedded. It was a success, giving us the "what the code does" functionality, but at a significant cost. Our launch tweet unexpectedly took off, and signups started pouring in. While this was exciting, it quickly became apparent that our backend architecture wasn't prepared for this level of demand. Worse, our approach was incredibly inefficient and expensive at scale. At our peak, we were processing nearly a quarter of a billion tokens per day. This was both a technical challenge and a financial nightmare. We were burning through thousands of dollars worth of tokens and constantly hitting our rate limits. Hard…but productive decisions One of our YC group partners, Tom Blomfield, gave us crucial advice: stop onboarding customers who were going to have a bad experience. It was tough to turn away potential users, but we knew that short-term disappointment would protect both parties from damage in the long term. We found ourselves at a bit of a crossroads. Suddenly our minimum viable product had lost the “viable” bit. We needed to figure out a way to deliver the same functionality without relying on an LLM for every query. We considered using a self-hosted LLM as an alternative, but the costs would still have been prohibitively high for our traffic levels. After a deeper analysis, we realized that having an LLM in the loop simply wasn't feasible with current technology. This led us to a solution that, while not groundbreaking, is often overlooked: creating a custom matrix to bias embeddings for our specific use case. Think of this as reorganising cookbooks based on how chefs actually search for recipes (e.g. cuisine or ingredients), rather than using a standard alphabetical system. This tailored approach helps find the right recipe much faster and more accurately, just as the custom matrix improves matching code snippets to user queries. We gathered a corpus of open-source code snippets from GitHub and used an LLM to generate synthetic user queries for each snippet. We then trained a model to optimize the embeddings for our particular domain. The results were impressive. Our accuracy jumped from 61% to around 90%, all without the need for constant LLM queries. This allowed us to maintain the core functionality of our product while drastically reducing costs and computational overhead. Our approach to data curation became increasingly sophisticated, and we developed a proprietary pipeline to generate datasets that truly capture the nuances of how human developers work. What we learned Be prepared to pivot: Our initial approach seemed promising, but it didn't hold up under real-world conditions. Being willing to completely rethink our architecture was what allowed us to survive. Monitor aggressively: We were caught off guard by the sudden surge in usage. Implementing better monitoring and alerting systems could have helped us respond more quickly. Understand your cost structure: We didn't fully grasp how our costs would scale with usage. This led to some painful financial realisations in those early days. Communicate clearly with users: Managing expectations during our rebuilding phase was challenging. We learned the importance of transparent communication, especially when dealing with technical users. Don't underestimate data quality: In rebuilding our system, we found that carefully curated, high-quality data was far more valuable than simply having more data. Be prepared to pivot: Our initial approach seemed promising, but it didn't hold up under real-world conditions. Being willing to completely rethink our architecture was what allowed us to survive. Monitor aggressively: We were caught off guard by the sudden surge in usage. Implementing better monitoring and alerting systems could have helped us respond more quickly. Understand your cost structure: We didn't fully grasp how our costs would scale with usage. This led to some painful financial realisations in those early days. Communicate clearly with users: Managing expectations during our rebuilding phase was challenging. We learned the importance of transparent communication, especially when dealing with technical users. Don't underestimate data quality: In rebuilding our system, we found that carefully curated, high-quality data was far more valuable than simply having more data. The road to Genie & the OpenAI validation The road to Genie & the OpenAI validation Our journey from a simple VS Code extension to Genie was marked by constant iteration and a willingness to pivot. We built what we could while waiting for AI technology to catch up to our vision. Our initial code search and retrieval system, cloud-based indexing platform, and experiments with emerging AI models all became crucial building blocks. When more advanced language models finally became available, we were uniquely positioned to integrate them with our existing tools, leading to the development of Genie - a fully autonomous AI software engineer that embodies our original vision. By October 2023, we had developed a proprietary technique to generate datasets that truly captured the nuances of how human developers work. This caught the attention of OpenAI, who granted us what was at the time rare early access to fine-tune GPT-4 beyond public availability. This collaboration allowed us to push the boundaries of what was possible with our approach, and in August 2024, we achieved a major milestone. Genie scored 43.8% on the industry-standard SWE-Bench Verified, significantly outperforming previous records held by major tech companies. Our product nearly broke under its own success. But we're now excited about the potential to transform how developers work. The bottom line is that the unprepared, underestimated success of a first product can derail a company, but it can also set it on a path to something a lot more meaningful than the founders initially imagined - if they  have the humility to challenge their own assumptions, like we did.

Our AI Coding Tool Went Viral, Then Everything Broke. This is What We Learned.

When Coding Determines the Survival of The City

Kodlaşdırma şəhərin sağ qalmasını təyin edərkən

Калі кадзіраванне вызначае выжыванне горада

Kada kodiranje određuje opstanak grada

Cuando la codificación determina la supervivencia de la ciudad

Kun koodaus määrittää kaupungin selviytymisen

Lè kodaj detèmine siviv vil la

コーディングが都市の存続を決定するとき

जब कोडिङले सहरको अस्तित्व निर्धारण गर्छ

Marka Codayntu Go'aamiso Badbaadada Magaalada

Коли кодування визначає виживання міста

当编码决定城市的生存

Lapho Ukufakwa Kwekhodi Kunquma Ukusinda Kwedolobha

When it comes to scalability, smart contract applications are the most advanced blockchain use case, they also use blockchain technology as their base. The benefit of such technology is the trust, safety, and integrity it provides, but as secure as they are, even the blockchain networks (more specific to smart contract networks) can be attacked. They’re automated which means they have their own terms and conditions coded directly in their code. This makes them able to be compromised because of logic flaws from the coding side and misuse or even potential external threats. Having secure smart contracts excludes a failure of blockchain security. These are the developer steps for securing and maintaining the trust of their smart contracts. Understanding Smart Contract Vulnerabilities Rather than jump into best practices for securing smart contracts, it is critical to first grasp where vulnerabilities can occur. Coding faults, logical issues, and external compromise are the most common threats, and often, result in millions of dollars in cash being lost or contracts working improperly. The so-called ‘DAO hack’ of 2016 exploited a reentrancy vulnerability in an Ethereum smart contract to steal $60 million worth of Ether. And this isn’t an isolated example. Without proper security policies, these types of issues continue to happen. For example, because blockchain is decentralized, unlike a contract written by a lawyer, a smart contract that has been executed ‘cannot be altered’ – a fact that only serves to make it more crucial that developers test their code to the utmost before it goes live. Rigorous Code Auditing and Testing Vulnerability elimination during smart contract development cannot be accomplished as effectively without exposing the code to audits and testing. Before deploying smart contracts to mainnet, they are evaluated in debugging, staging, and other test environments. Unit tests should be performed on each deployed function and use cases that each of them has been designed to facilitate. Besides manual and automatic auditing, one of the most important steps is using both manual and automated auditing technologies. Manual audits are not enough since logic flaws often reside within the code; automated tools such as MythX and Securify have a wider net for detecting bugs such as integer overflows, reentrancy, and DoS. Another excellent practice is to carry out external audits by specialist information security companies. They provide disinterested opinions and help to find the missing elements. Da Vinci, who is a family guy who also works as a scientist, explains Taoism as an insurmountable revolution where errors have to be accepted and later fixed by informing about their presumable occurrence before they occur. In the best case, a scorer stands useful in approving such conclusions. Avoiding Overcomplicated Logic Guaranteeing the convenience of the used interfaces is the first thing to keep in mind while elaborating smart contracts. With sophistical logic, the chances of going wrong and the doors for unnecessary dependencies become too numerous, hence increasing the difficulties in the review and maintenance of the code. Each operation, emitted by a smart contract, has to be kept simple, visible, and short. So, it is necessary to avoid the temptation to try to make a contract multifunctional bathe in highly complex logic. Implementing Upgraded Contract An obstacle that comes with smart contracts is their immutability. Once deployed on-chain, the deployed code is acceptable as is, without any amendments. This, however, can be cured through the construction of upgradable contracts, which permit the change of some aspects of a contract after its deployment. Though this feature enhances flexibility, it may also pose some risks in terms of security if not implemented properly. People working in this area should ensure that the mechanism that enables an upgrade is robust enough to be immune to hostile abuse. The use of the OpenZeppelin proxy library provides proxy patterns that help build convenient upgradeable contracts. Also, escalation controls should be designed in such a way as to protect upgrades from unauthorized initiators. Protecting Against Reentrancy Attack Reentrancy stands as a common exploit avenue in smart contracts and has featured prominently in illustrious breaches. This flaw manifests when an external contract triggers a function inside the smart contract while the initial transaction lingers in completion, leading to unanticipated actions. Developers ought to employ checks-effects-interactions strategies to shield against reentrancy threats. This method involves altering the contract's state ahead of any external calls. Additionally, mutexes may be employed to mitigate reentrancy hazards by limiting concurrent engagements with a contract. Ensuring Proper Gas Utilization Skillfully governing gas usage is vital for the fortification of smart contracts. Gas fuels transactions on networks like Ethereum, and contracts guzzling too much gas risk falling prey to DoS attacks. Excessive gas use might cause a contract to malfunction, potentially trapping funds or freezing the contract. To avert this risk, developers must refine their code for efficiency, trimming redundant calculations and outside requests. Establishing suitable gas limits during contract execution is key to staving off DoS attacks due to gas exhaustion, thus protecting the contracts. Leverage Decentralized Oracle With Caution Numerous smart contracts hinge on external data for their functionality, often sourced from decentralized entities called oracles. These oracles serve as conduits between the blockchain and the tangible world but also represent a potential vulnerability as a target for attacks. Should an assailant seize an oracle, it might supply erroneous information to the smart contract, leading to flawed outcomes. To mitigate such risks, developers should turn to decentralized oracles with a robust track record of reliability. Employing diverse data sources to cross-verify information can also diminish the likelihood of manipulation. Moreover, developers must embed contingency measures within the smart contract to secure its operations if the oracle is compromised or malfunctions. Implementing Multisig Wallets Developers are advised to consider the integration of multi-signature wallets for critical operations like large fund transfers or contract upgrades. These wallets necessitate the consent of multiple parties to execute transactions, adding a defensible layer of security. Multisig wallets thwart unauthorized activities by ensuring that solitary entities cannot exert unilateral control over the contract. This is particularly advantageous in decentralized finance (DeFi) platforms, where significant assets are susceptible to risk. Continuous Monitoring and Response Plan Ensuring security in smart contracts requires continuous attention and effort. Continuous monitoring remains crucial after deployment to guarantee the continued safety of the contract. It is important for developers to frequently monitor smart contract activity for any abnormal actions, such as significant withdrawals or contract calls that differ from anticipated patterns. Furthermore, a strong incident response plan is essential. Having a response plan in place enables developers to quickly address and reduce damage when vulnerabilities are found after deployment. Developers may choose to add self-destruct features or safety mechanisms to their contracts as a response to identified exploits. Conclusion The security of clever contracts holds significant weight in the blockchain realm. With the rise in decentralized apps, crafting watertight smart contracts free from vulnerabilities becomes increasingly crucial. Following such rules, for example, performing comprehensive audits, avoiding excessive complexity, preventing reentrancy, or effective management of gas, allows software developers to lower the probability of exploitation and ensure that their smart contracts will function properly. In the fast-evolving world of blockchain, the attention of the users, the simplicity of the systems, and security measures can preserve the assets and confidence in the distributed system. When it comes to scalability, smart contract applications are the most advanced blockchain use case, they also use blockchain technology as their base. The benefit of such technology is the trust, safety, and integrity it provides, but as secure as they are, even the blockchain networks (more specific to smart contract networks) can be attacked. They’re automated which means they have their own terms and conditions coded directly in their code. This makes them able to be compromised because of logic flaws from the coding side and misuse or even potential external threats. Having secure smart contracts excludes a failure of blockchain security. These are the developer steps for securing and maintaining the trust of their smart contracts. Understanding Smart Contract Vulnerabilities Understanding Smart Contract Vulnerabilities Rather than jump into best practices for securing smart contracts, it is critical to first grasp where vulnerabilities can occur. Coding faults, logical issues, and external compromise are the most common threats, and often, result in millions of dollars in cash being lost or contracts working improperly. The so-called ‘DAO hack’ of 2016 exploited a reentrancy vulnerability in an Ethereum smart contract to steal $60 million worth of Ether. And this isn’t an isolated example. Without proper security policies, these types of issues continue to happen. For example, because blockchain is decentralized, unlike a contract written by a lawyer, a smart contract that has been executed ‘cannot be altered’ – a fact that only serves to make it more crucial that developers test their code to the utmost before it goes live. Rigorous Code Auditing and Testing Rigorous Code Auditing and Testing Vulnerability elimination during smart contract development cannot be accomplished as effectively without exposing the code to audits and testing. Before deploying smart contracts to mainnet, they are evaluated in debugging, staging, and other test environments. Unit tests should be performed on each deployed function and use cases that each of them has been designed to facilitate. Besides manual and automatic auditing, one of the most important steps is using both manual and automated auditing technologies. Manual audits are not enough since logic flaws often reside within the code; automated tools such as MythX and Securify have a wider net for detecting bugs such as integer overflows, reentrancy, and DoS. Another excellent practice is to carry out external audits by specialist information security companies. They provide disinterested opinions and help to find the missing elements. Da Vinci, who is a family guy who also works as a scientist, explains Taoism as an insurmountable revolution where errors have to be accepted and later fixed by informing about their presumable occurrence before they occur. In the best case, a scorer stands useful in approving such conclusions. Avoiding Overcomplicated Logic Avoiding Overcomplicated Logic Guaranteeing the convenience of the used interfaces is the first thing to keep in mind while elaborating smart contracts. With sophistical logic, the chances of going wrong and the doors for unnecessary dependencies become too numerous, hence increasing the difficulties in the review and maintenance of the code. Each operation, emitted by a smart contract, has to be kept simple, visible, and short. So, it is necessary to avoid the temptation to try to make a contract multifunctional bathe in highly complex logic. Implementing Upgraded Contract Implementing Upgraded Contract An obstacle that comes with smart contracts is their immutability. Once deployed on-chain, the deployed code is acceptable as is, without any amendments. This, however, can be cured through the construction of upgradable contracts, which permit the change of some aspects of a contract after its deployment. Though this feature enhances flexibility, it may also pose some risks in terms of security if not implemented properly. People working in this area should ensure that the mechanism that enables an upgrade is robust enough to be immune to hostile abuse. The use of the OpenZeppelin proxy library provides proxy patterns that help build convenient upgradeable contracts. Also, escalation controls should be designed in such a way as to protect upgrades from unauthorized initiators. Protecting Against Reentrancy Attack Protecting Against Reentrancy Attack Reentrancy stands as a common exploit avenue in smart contracts and has featured prominently in illustrious breaches. This flaw manifests when an external contract triggers a function inside the smart contract while the initial transaction lingers in completion, leading to unanticipated actions. Developers ought to employ checks-effects-interactions strategies to shield against reentrancy threats. This method involves altering the contract's state ahead of any external calls. Additionally, mutexes may be employed to mitigate reentrancy hazards by limiting concurrent engagements with a contract. Ensuring Proper Gas Utilization Ensuring Proper Gas Utilization Skillfully governing gas usage is vital for the fortification of smart contracts. Gas fuels transactions on networks like Ethereum, and contracts guzzling too much gas risk falling prey to DoS attacks. Excessive gas use might cause a contract to malfunction, potentially trapping funds or freezing the contract. To avert this risk, developers must refine their code for efficiency, trimming redundant calculations and outside requests. Establishing suitable gas limits during contract execution is key to staving off DoS attacks due to gas exhaustion, thus protecting the contracts. Leverage Decentralized Oracle With Caution Leverage Decentralized Oracle With Caution Numerous smart contracts hinge on external data for their functionality, often sourced from decentralized entities called oracles. These oracles serve as conduits between the blockchain and the tangible world but also represent a potential vulnerability as a target for attacks. Should an assailant seize an oracle, it might supply erroneous information to the smart contract, leading to flawed outcomes. To mitigate such risks, developers should turn to decentralized oracles with a robust track record of reliability. Employing diverse data sources to cross-verify information can also diminish the likelihood of manipulation. Moreover, developers must embed contingency measures within the smart contract to secure its operations if the oracle is compromised or malfunctions. Implementing Multisig Wallets Implementing Multisig Wallets Developers are advised to consider the integration of multi-signature wallets for critical operations like large fund transfers or contract upgrades. These wallets necessitate the consent of multiple parties to execute transactions, adding a defensible layer of security. Multisig wallets thwart unauthorized activities by ensuring that solitary entities cannot exert unilateral control over the contract. This is particularly advantageous in decentralized finance (DeFi) platforms, where significant assets are susceptible to risk. Continuous Monitoring and Response Plan Continuous Monitoring and Response Plan Ensuring security in smart contracts requires continuous attention and effort. Continuous monitoring remains crucial after deployment to guarantee the continued safety of the contract. It is important for developers to frequently monitor smart contract activity for any abnormal actions, such as significant withdrawals or contract calls that differ from anticipated patterns. Furthermore, a strong incident response plan is essential. Having a response plan in place enables developers to quickly address and reduce damage when vulnerabilities are found after deployment. Developers may choose to add self-destruct features or safety mechanisms to their contracts as a response to identified exploits. Conclusion Conclusion The security of clever contracts holds significant weight in the blockchain realm. With the rise in decentralized apps, crafting watertight smart contracts free from vulnerabilities becomes increasingly crucial. Following such rules, for example, performing comprehensive audits, avoiding excessive complexity, preventing reentrancy, or effective management of gas, allows software developers to lower the probability of exploitation and ensure that their smart contracts will function properly. In the fast-evolving world of blockchain, the attention of the users, the simplicity of the systems, and security measures can preserve the assets and confidence in the distributed system.

Ensuring Security in Smart Contract Applications: The Importance of Robust Coding Practices

Coding Exercise: Database Migration Tool in Nodejs

Stories, News & Mentions about CODI

Codi’s Stories on HackerNoon