Architecture Behind Sila Ethereum Transactions

https://silamoney.com/2019/07/08/using-aws-lambda-sqs-with-web3/
https://silamoney.com/2019/07/08/using-aws-lambda-sqs-with-web3-2/

Major components

1. DynamoDB to store the nonce associated with ethereum addresses authorized to send ethereum smart contract transactions
2. Lambda functions triggered by SQS events for SilaToken issuance, redemption, and transfer messages
3. Ethereum RPC EC2 servers running Parity Ethereum client
4. AWS Secrets Manager to store private keys being used to sign the transactions
5. Orchestrator as a bridge between REST API, ACH, and ethereum transactions. Orchestrator is a piece of code that handles the transaction state and reroutes them to right queue.
6. SQS as an interface between different services like REST API, ACH, Ethereum issuance, redemption, and transfers.

Transaction Lifecycle

Messages for SilaToken issuance, redemption, and transfer comes in through Sila APIs. Dependent on the action (issue, redeem, and transfer), the message is sent to the relevant queue by Orchestrator, which in turn triggers the send transaction Lambda function.

That sends the transaction, signed by Sila’s authorized address, to Ethereum node and increases the nonce in the database by one, for subsequent transactions. The message is deleted from the ethereum transaction queue and sent to the ethereum pending queue with the transaction hash and nonce, then sent with the block number appended in the message history. Replace and check for transaction send failure if there is a bad RPC connection.

Constructing a Transaction:

Sending a transaction:

Nonce management

After experimenting with several ways to manage the authorized address nonce we settled on storing it in a database, as it is faster to retrieve and update there than making a Web3 call to the RPC server and waiting for the transaction to be mined. It has its pitfalls, however. For example, subsequent transactions can get stuck until previous transactions have been mined, but that’s why we have three Lambda functions that are watching just the pending transactions — and we’ll discuss how to handle pending ethereum smart contract transactions in the next section.

Nonce management is not as straightforward, as we have three Lambda functions that can send transactions. In our case we have conditions in place that are dependent on message history.

Deciding gas price & gas limit

Gas limit is set based on the amount of computation involved in the smart contract function call. However we can play around with the gas price to make sure transactions are being mined in the desired time. We use a modified version of eth_gas_station engine to decide the gas price, based on the network mining requirements.

Handling Transactions in Pending Queue

Let’s dive deeper into the three Lambda functions that are watching the pending queue . . .

1. Check pending transactions for success or a fail

Previously we discussed how we appended the tx_hash, nonce and sent_at_blockNumber in the message history, we use tx_hash and web3 module to get the transaction status. The transaction status can be 0,1, or null depending on if the transaction has been mined successfully. Status 0 and 1 both result in a nonce increment for the authorized address, as the transaction was mined in some block. If the status is 0, which means the transaction failed, we retry the transaction by sending it back to the transaction queue. Each transaction is restricted to a maximum of 3 retries, after which it is dumped into Orchestrator. If the status is 1 which means that the transaction was successful, a message with success update is sent to Orchestrator.

2. Replacing stuck transactions

If the transaction hash gets a null and transaction has been pending in the node memory pool for a long time, consider how we appended the sent_at_block number and nonce in the message history. We get the current block number, using Web3, and compare the difference; if the difference is more than 80 blocks (and the difference can be set to higher or lower), which means the transaction has been pending for 80 blocks, we replace the transaction with a higher gas price, keeping the nonce value the same as in the message.

3. Handling transaction send failures

If you play with Ethereum long enough you will have certain cases where you are unable to find the sent transaction in the node memory pool. This means the transaction never hit the Ethereum RPC server, but we have another Lambda function that will redirect the transaction message to the queue.

Like this article? Share it with your network!

About Sila

Sila provides Banking and Payments Infrastructure-as-a-Service for teams building the next generation of financial products and services. Our banking API replaces the need for integrating with legacy financial institutions saving you months of development time and thousands in legal and regulatory expenses.

haproxy failover backup server

https://www.haproxy.com/blog/failover-and-worst-case-management-with-haproxy/

Normal backup servers： In this case, s3 will be used first, until it fails, then s4 will be used.

frontent ft_app
 bind 10.0.0.1:80
 default_backend bk_app_main
backend bk_app_main
 server s1 10.0.0.101:80 check
 server s2 10.0.0.102:80 check
 server s3 10.0.0.103:80 check backup
 server s4 10.0.0.104:80 check backup

Multiple backup servers： In this case, both s3 and s4 will be used if they are available.

option allbackups

frontent ft_app
 bind 10.0.0.1:80
 default_backend bk_app_main
backend bk_app_main
 option allbackups
 server s1 10.0.0.101:80 check
 server s2 10.0.0.102:80 check
 server s3 10.0.0.103:80 check backup
 server s4 10.0.0.104:80 check backup

nginx failover without load balancing

https://serverfault.com/questions/480241/nginx-failover-without-load-balancing

pstream backend {
    server 1.2.3.4:80 fail_timeout=5s max_fails=3;
    server 4.5.6.7:80 backup;
}

server {
    listen 80;
    server_name whatevs.com;

    location / {
        proxy_pass http://backend;
    }
}

https://www.cnblogs.com/biglittleant/p/8979887.html

backup 预留的备份服务器，当其他所有的非backup服务器出现故障或者忙的时候，才会请求backup机器，因为这台集群的压力最小。

max_fails 允许请求失败的次数，默认是1，当超过最大次数时，返回proxy_next_upstream模块定义的错误。0表示禁止失败尝试，企业场景：2-3.京东1次，蓝汛10次，根据业务需求去配置。

fail_timeout，在经历了max_fails次失败后，暂停服务的时间。京东是3s，蓝汛是3s，根据业务需求配置。常规业务2-3秒合理。

例：如果max_fails是5，他就检测5次，如果五次都是502.那么，他就会根据fail_timeout 的值，等待10秒，再去检测。


https://blog.51cto.com/wangwei007/1103727

ethereum Nonce collisions

https://hackernoon.com/ethereum-blockchain-in-a-real-project-with-500k-users-f85ee4821b12

Nonce collisions
Nonce collisions were another mysterious thing we’ve encountered when trying to scale the number of Geth nodes in order to cover the case when one node crashes. It turns out that


We used a simple load balancer before the three Geth nodes, which was sending each transaction to one of the three nodes. The problem was that each time we submitted many transactions at once, some of those transactions were mysteriously disappearing. It took a day or two until we finally figured out that this was a problem with nonce collisions.

When you are submitting raw transactions to the network you are fine, because you keep track of nonce numbers yourself. In this case you just need a node to publish raw transactions to the network. But in the case you are using an account unlocking mechanism built into the node and do not specify the nonce when publishing transactions (with web3 or so), the node tries to pick the appropriate nonce value itself and then signs a transaction.

Because of the network delays, in the case two nodes receive the same transaction publishing request, they can generate the same nonce value. At the moment of receiving the transaction publishing request they don’t know that they both received a transaction with the same nonce. Thus, when propagating these transactions through the network, one of them will eventually be dropped because its “transaction nonce is too low”.

To fix nonce collisions introduced by adding a load balancer to a system, we needed to create a different kind of load balancer. For example, a load balancer which always uses one particular node and switches to another node only if the first one is down.

ethereum Proper Transaction Signing nonce

https://ethereum.stackexchange.com/questions/12823/proper-transaction-signing

const Web3 = require('web3');
const Tx = require('ethereumjs-tx');
const config = require('./config');

const web3 = new Web3(new Web3.providers.HttpProvider(config.provider)); //link provided by Infura.io
web3.eth.defaultAccount = "0xc929c890f1398d5c1ecdf4f9ecec016906ac9f7f";

const getNonce = () => {
  return new Promise((resolve, reject) => {
    web3.eth.getTransactionCount(web3.eth.defaultAccount, (error, result) => {
      if(error) reject(error);
      resolve(web3.toHex(result));
    })
  })
}
const getGasPrice = () => {
  return new Promise((resolve, reject) => {
    web3.eth.getGasPrice((error, result) => {
      if(error) reject(error);
      resolve(web3.toHex(result.toNumber()));
    })
  })
}

const sendRawTransaction = (rawTx) => {
  const privateKey = "190b820c2627f26fd1b973b72dcba78ff677ca4395c64a4a2d0f4ef8de36883c";
  const tx = new Tx(rawTx);
  const privateKeyBuffer = Buffer.from(privateKey, 'hex');
  tx.sign(privateKeyBuffer);
  const serializedTx = tx.serialize();
  web3.eth.sendRawTransaction('0x' + serializedTx.toString('hex'), function(err, hash) {
      console.log('Error:', err);
      console.log('Hash:', hash);
  });
}

Promise.all([getNonce(), getGasPrice()])
  .then(values => {
    const rawTx = {
      to: '0x203D17B4a1725E001426b7Ab3193E6657b0dBcc6',
      gasLimit: web3.toHex(1000000),
      value: web3.toHex(web3.toWei('0.1', 'ether')),
      nonce: values[0],
      gasPrice: values[1]
    };
    console.log(rawTx);
    return(rawTx);
  })
  .then(sendRawTransaction)
  .catch(e => console.log(e))

ring buffer

https://zhen.org/blog/ring-buffer-variable-length-low-latency-disruptor-style/

https://github.com/smartystreets-prototypes/go-disruptor

ethereum transaction template

https://ethereum.stackexchange.com/questions/50042/why-does-sendsignedtransaction-return-a-tx-hash-but-does-not-post-to-the-rinkeby

window.web3 = new Web3(new Web3.providers.HttpProvider(endpoint));

sendEther() {
    const fromAccount = **acct1**;
    const toAccount   = **acct2**;

    const rawTransaction    = this.makeRawTransaction(fromAccount, toAccount);
    const signedTransaction = this.makeSignedTransaction(rawTransaction);
    const serializedTransaction = `0x${signedTransaction.serialize().toString('hex')}`;

    window.web3.eth.sendSignedTransaction(serializedTransaction, (error, result) => {
        if(!error) {
          console.log(`Transaction hash is: ${result}`);
          this.setState({
            etherscanUrl: `https://rinkeby.etherscan.io/tx/${result}`,
            error: null
          });

        } else {
          this.setState({ error: error.message })
          console.error(error);
        }
    });
  }

  makeSignedTransaction(rawTransaction) {
    const privateKey   = '**************';
    const privateKeyX  = new Buffer(privateKey, 'hex');
    const transaction  = new EthTx(rawTransaction);
    transaction.sign(privateKeyX);

    return transaction;
  }

  makeRawTransaction(fromAccount, toAccount) {
    const { exchangeRate } = this.props;
    const amount = (1 / exchangeRate) * 5;

    return ({
      nonce: window.web3.utils.toHex(window.web3.eth.getTransactionCount(fromAccount)),
      to: toAccount,
      gasPrice: window.web3.utils.toHex(100000000000),
      gasLimit: window.web3.utils.toHex(100000),
      value: window.web3.utils.toHex(window.web3.utils.toWei(`${amount}`, 'ether')),
      data: ''
    });
  }

[轉]Windows、WSL 与 Linux 的性能对比

https://www.cnbeta.com/articles/tech/922349.htm

尽管执行了各种各样的测试，但是如果对在七个不同操作系统上成功运行的所有测试取几何平均值，可以得出这样的结论：

Windows 10 Build 19008 的总体性能要比 Build 18362 版本好，而 WSL 的性能并没有太大变化

WSL2 比 WSL 的性能确实稍好一些，这是因为在 I/O 或网络活动繁重的工作负载的情况下前者性能要好得多

在这种特殊的 Core i9 7960X 场景下，运行 Ubuntu Linux 的速度总体上比最快的 Windows 配置快 27％

有兴趣的朋友可查看这份更详细的 OpenBenchmarking.org 结果文件，以深入研究这些 Windows / WSL / Linux 基准测试内容。

geth attach

geth --exec "eth.blockNumber" attach --datadir ./
geth --exec "eth.syncing" attach --datadir ./
geth --exec "admin.peers" attach --datadir ./
geth --exec "clique.getSnapshot()" attach --datadir ./

watch -n 2 'geth --exec "clique.getSnapshot()" attach --datadir ./'

geth-prometheus

https://github.com/karalabe/geth-prometheus

https://blog.ethereum.org/2019/07/10/geth-v1-9-0/

You can quickly reproduce the above charts via my clone of Maxim Krasilnikov’s project by running docker-compose up in the repo root and accessing http://localhost:3000 with the admin/admin credentials. Alternatively, you can view my testing snapshot on Raintank, or import this dashboard into your own Grafana instance

源碼掃瞄

Checkmarx
Fortify