Solution - End User Issues

This end user issue is solved by AltExecCNSAPI.

The details of which are explained later.

Problem of local Ethereum Node and End-user Ether

We will resolve both problems at once.

Generally, when you try to generate and sign an Ethereum transaction and send it to the Ethereum network, a local Ethereum node connects to the Ethereum network and to send transactions to the network.


The Ethereum node needs to hold all past transactions and blocks, and this is not very realistic for smartphones, IoT equipment etc with limited resources.

In order to work around this, this service provides an API for signing on behalf of the user.

API for signing on behalf of users

For the issue of being unable to run a local ethereum node on the end user terminal and the issue of possession of Ether, the API server simply receives the request from the end user, signs it on the API server instead and transmits the transaction to Ethereum.

Alternative transaction image

Now, the end user terminal does not have to run an Ethereum node, and it does not issue transactions, so virtual currency is no longer necessary.

However, this process has some new problems.

From here we will deal with each problem.

Process reliability problem


    Originally Ethereum's transactions are recognized as trustworthy because all transactions processed are signed with the user's signature.

    However, in this architecture, the intervening API server can change transactions in any way it likes.


    Change to the processing flow as follows.

    1. All the request contents are signed on the client side similar to signing a transaction.
    2. The service API accepts the request contents and signature data, and places it in a transaction as it is.
    3. On the Contract side the address is obtained from the end user's signature, and only users with processing authority are processed.

    Hence, user's can not run the Ethereum contract unless they provide a valid signature, and an alternative signing account is used for the transaction GAS payment while maintaining the trust level of Ethereum.


API node payment problem


    In the previous solution, the end user no longer signs and issues transactions, so end users no longer need to have Ether.
    Instead, the API server generates transactions and records them in the Ethereum network, so it has become necessary for the API server to bear the cost.


    When an end user issues a transaction via the API server, he/she always does so using the service provider's CNS address as a starting point.

    var contract = new AltExecCnsContract(account);, '0x___CNSADDRESS___', 'Building', 'getRoomIds', ['building1'], abi, function(err, res) {
        if (err) console.error(err);
        else console.log(res.join(','));

    In this way it is possible to support version upgrades even from providers.

    1. The API server accepts requests from end users.
    2. The API server checks which provider the CNS address belongs to. (If no error is returned)
    3. The API server issues the transaction using the alternative signing account of the provider.

    Only the provider can register contracts with the CNS, only the contracts provided can be used by the user, and the service provider will be only be charged for the contracts he/she offers.

Problem of attack with overly expensive transaction calls


    If unauthorized access occurs to the CNS provided by the service provider, GAS may be consumed in large amounts due to a large amount of transaction processing.


    The process flow of the alternative account payment is as follows.

    1. The API server accepts requests from end users.
    2. The API server checks which provider the CNS address belongs to. (If no error is returned)
    3. The API server calculates the GAS consumed by the estimate GAS before the Transation is executed.
    4. When reaching GASLIMIT specified by service provider, terminate without initiating the Transaction.
    5. The API server issues Transaction with substitution KeyPair of the target provider.

    By inserting the above 3 and 4, even if an attack or the like occurs, consumption of GAS will not occur as the check done will terminate with a throw.

results matching ""

    No results matching ""