Creation of scalability on Ethereum



[ad_1]
<div _ngcontent-c15 = "" innerhtml = "

Getty

Being part of a massive fundamental shift, like what is occurring in the spaces of blockchains and distributed systems, is a double-edged sword. It's a fun opportunity for your career, but it can be daunting, as it solves many problems for the first time. & Nbsp; Even a simple bug can be a huge task to overcome.

Those who build decentralized applications have experimented over and over again. A challenge that my team and I have met is reaching the scalability on the Ethereum blockchain, which we use for payments on our platform. Others have discussed the scalability of Ethereum in recent weeks. As mentioned in & nbsp;Here, what many overlook is that every emerging platform struggles to climb soon. Despite its problems, Ethereum is still in the best position to climb in the long run.

Discovering the challenges that arise in the ether

Transaction fees are a major concern of the community. For people who send Ethereum, commissions in the $ 1- $ 2 range do not seem high. Chances are you're sending a high value transaction, so the commission makes up a small percentage of the total payment. When sending large volumes of transactions required for real-world applications, that rate of $ 2 out of 150,000 payments quickly increases to $ 300,000.

Our decentralized cloud storage network is made up of people who share unused hard drive space in exchange for STORJ, our Ethereum-based utility token. At the moment we make monthly payments to our community.

Last March, our team found a huge milestone in payment volume. We have sent over 145,000 payments in a week. Ethereum processes 15 payments per second, & nbsp; in the sense that if the network only managed our payments, it would take more than four hours to complete. Because of this volume, we aim to send transactions when rates are low.

Apart from the problems, we were impressed that we can make so many payments with standard laptops, a script and payment data. & Nbsp;

Find solutions to resize problems one at a time

When solving multiple problems within a platform, it is best to solve them one by one to see how each change affects the whole ecosystem. Our payment problems began to get complicated when the volume of Ethereum transactions began to exceed 100,000 a month. The obstacles were related to several things, including the web3.js library used in our node.js payment application, the Parity Ethereum nodes that managed the interaction with the blockchain, the configuration at the operating system level and the specific problems of the Ethereum chain.

We started by updating our web3.js library to fix numerous bugs and take advantage of new features. Initially, we were using a simple node.js script to process payments, which did not attempt to confirm transactions or handle many error cases. The latest bookstore allowed us to use new features to overcome many of our problems, and the rest was relatively easy to get around.

Our problems with Parity were among the most difficult we encountered. We managed our Parity nodes to securely transmit all the transactions we wanted to transmit. However, the local queue would be filled and would cause the node to stop local transactions in favor of other transactions, making it difficult to check their status. We solved this problem by carefully managing nonce, a number that the network uses to identify transactions per account, increasing by one unit each time a different transaction is sent per account. This is highly recommended if you are pushing out substantial transaction volume and is relatively easy to implement using Parity.

Outside the box, Parity also struggled with a large number of simultaneous transactions. This required a fine-tuning of the command line parameters to be solved. This gave rise to a new bottleneck: a node could not forward transactions to the network fast enough. Executing multiple nodes has solved this problem by increasing the maximum transaction throughput.

Many other problems have also been solved by Parity. In previous versions, there were delays between sending the transaction and the time it was displayed in queries. Things in this area are changing so rapidly that it can be difficult to stay up-to-date with the latest updates and innovations.

The last area we encountered was related to configuration and adjustment at the operating system level. When processing large volumes of transactions, it is essential to increase the number of available TCP connections and the maximum number of files open for the Parity process user. After tuning them appropriately, we found excellent results.

Scalability of the Ethereum network

The future of the Ethereum network depends on effective scalability with increasing demand. There are two considerations to keep in mind when resolving Ethereum transaction throughput scalability challenges. The first is the fact that each transaction must be completed by each node. This intrinsically means that adding more nodes to the network will never help scalability, but only security. The second is that all transactions, no matter how small, must go through the main network.

The first possible solution is sharding, which breaks the Ethereum network into logical blocks that can process multiple transactions independently and securely. With the increase in demand and the growth of the network, this is resized in a dynamic and potentially indefinite way.

The second is Raiden Network, which allows for off-chain, fast, low-cost transactions based on a pre-defined smart etereum contract between two parties. At any time, each party may terminate the contract, resulting in an agreement with the payee for the amount due, returning the remaining funds from the commitment to the payer. Ultimately, I think the answer is a combination of both solutions.

It is often said that necessity is the mother of innovation. The more cases of use of Ethereum in the real world emerge, the faster we will achieve scalability. There are about 2.6 million seconds in a month, which implies that the network can handle around 26 million transactions during that time period. This means that it will take less than 200 companies of our size to completely saturate the Ethereum blockchain. With the whole community of blockchain and decentralization working together with this, I am confident that we will soon have the solutions we all need.

Forbes technological council is an invitation-only community for CIOs, CTOs and world-class technology executives.
Do I qualify?

">

Being part of a massive fundamental shift, like what is occurring in the spaces of blockchains and distributed systems, is a double-edged sword. It's a fun opportunity, which creates a career, but it can be daunting, as it often solves many problems for the first time. Even a simple bug can be a huge task to overcome.

Those who build decentralized applications have experimented over and over again. A challenge that my team and I have met is reaching the scalability on the Ethereum blockchain, which we use for payments on our platform. Others have discussed the scalability of Ethereum in recent weeks. As mentioned here, what many overlook is that every emerging platform struggles to climb soon. Despite its problems, Ethereum is still in the best position to climb in the long run.

Discovering the challenges that arise in the ether

Transaction fees are a major concern of the community. For people who send Ethereum, commissions in the $ 1- $ 2 range do not seem high. Chances are you're sending a high value transaction, so the commission makes up a small percentage of the total payment. When sending large volumes of transactions required for real-world applications, that rate of $ 2 out of 150,000 payments quickly increases to $ 300,000.

Our decentralized cloud storage network is made up of people who share unused hard drive space in exchange for STORJ, our Ethereum-based utility token. At the moment we make monthly payments to our community.

Last March, our team found a huge milestone in payment volume. We have sent over 145,000 payments in a week. The processes of Ethereum about 15 payments per second, in the sense that if the network managed only our payments, it would take more than four hours to complete. Because of this volume, we aim to send transactions when rates are low.

Apart from the problems, we were impressed that we can make so many payments with standard laptops, a script and payment data.

Find solutions to resize problems one at a time

When solving multiple problems within a platform, it is best to solve them one by one to see how each change affects the whole ecosystem. Our payment problems began to get complicated when the volume of Ethereum transactions began to exceed 100,000 a month. The obstacles were related to several things, including the web3.js library used in our node.js payment application, the Parity Ethereum nodes that managed the interaction with the blockchain, the configuration at the operating system level and the specific problems of the Ethereum chain.

We started by updating our web3.js library to fix numerous bugs and take advantage of new features. Initially, we were using a simple node.js script to process payments, which did not attempt to confirm transactions or handle many error cases. The latest bookstore allowed us to use new features to overcome many of our problems, and the rest was relatively easy to get around.

Our problems with Parity were among the most difficult we encountered. We managed our Parity nodes to securely transmit all the transactions we wanted to transmit. However, the local queue would be filled and would cause the node to stop local transactions in favor of other transactions, making it difficult to check their status. We solved this problem by carefully managing nonce, a number that the network uses to identify transactions per account, increasing by one unit each time a different transaction is sent per account. This is highly recommended if you are pushing out substantial transaction volume and is relatively easy to implement using Parity.

Outside the box, Parity also struggled with a large number of simultaneous transactions. This required a fine-tuning of the command line parameters to be solved. This gave rise to a new bottleneck: a node could not forward transactions to the network fast enough. Executing multiple nodes has solved this problem by increasing the maximum transaction throughput.

Many other problems have also been solved by Parity. In previous versions, there were delays between sending the transaction and the time it was displayed in queries. Things in this area are changing so rapidly that it can be difficult to stay up-to-date with the latest updates and innovations.

The last area we encountered was related to configuration and adjustment at the operating system level. When processing large volumes of transactions, it is essential to increase the number of available TCP connections and the maximum number of files open for the Parity process user. After tuning them appropriately, we found excellent results.

Scalability of the Ethereum network

The future of the Ethereum network depends on effective scalability with increasing demand. There are two considerations to keep in mind when resolving Ethereum transaction throughput scalability challenges. The first is the fact that each transaction must be completed by each node. This intrinsically means that adding more nodes to the network will never help scalability, but only security. The second is that all transactions, no matter how small, must go through the main network.

The first possible solution is sharding, which breaks the Ethereum network into logical blocks that can process multiple transactions independently and securely. With the increase in demand and the growth of the network, this is resized in a dynamic and potentially indefinite way.

The second is Raiden Network, which allows for off-chain, fast, low-cost transactions based on a pre-defined smart etereum contract between two parties. At any time, each party may terminate the contract, resulting in an agreement with the payee for the amount due, returning the remaining funds from the commitment to the payer. Ultimately, I think the answer is a combination of both solutions.

It is often said that necessity is the mother of innovation. The more cases of use of Ethereum in the real world emerge, the faster we will achieve scalability. There are about 2.6 million seconds in a month, which implies that the network can handle around 26 million transactions during that time period. This means that it will take less than 200 companies of our size to completely saturate the Ethereum blockchain. With the whole community of blockchain and decentralization working together with this, I am confident that we will soon have the solutions we all need.

[ad_2]
Source link