search

ETH-Pantheon / Aion

A system for Scheduling transactions with arbitrary bytecode on the Ethereum Network
https://www.aion.ethpantheon.com
MIT License
26 stars 13 forks source link

Decentralization of Aion #6

Open jfdelgad opened 5 years ago

jfdelgad commented 5 years ago

@ETH-Pantheon Aion has been designed having in mind trustlessness as principal feature. This is achieved through smart contract functionality which makes impossible to modify a transaction data. Furthermore, Aion executor only receives fee payments if the transaction is executed correctly.

Despite this, the issue of having a centralized executor cause discomfort among the users as if the executor disappear (for any unthinkable reason) the apps that use recurrent calls will lose the functionality.

I am open this issue aiming to motivate the implementation of a mechanism that allows other people interested in executing a transaction to participate, reducing the dependency on Aion executer.

I propose to make the executor itself a smart contract that can be called by other EOA to execute the transaction in Aion smart contract.

Things to define are:

  1. How a random account can become an executor.
  2. What mechanism should be used to select the executor (in ethereum alarm clock people could lose money as the selection of the executors is not defined so executors fight for transactions by claiming them)
  3. will the executors be punished for missing a scheduled transaction assigned to them?
  4. What if an executor misses a transaction, should it be picked up by another executor?
ETH-Pantheon commented 5 years ago

The system was designed to be trustless and our emphasis is on that. However, the idea to make the system decentralized is welcomed. Some issues could appear as a consequence. First, the fees that we have been established are pretty low compared to other services, having many executors at the fee level that we offer will be of little incentive for executors. We believe that the emphasis of decentralization should be focused on ensuring that if for any unforeseen reason our cloud servers stop working, any other person can execute the transactions. In the current implementation, the contract has an admin (us). this can be overcome by making a proxy contract the admin, that contract can allow anyone (maybe some conditions should be imposed to prevent abuse) to execute transactions in a first-to-come first-served or maybe just randomly selecting from the set of executors interested.

We propose to start this by making a proxy contract that takes control of Aion and accepts executors. Executors should be selected fairly to avoid dominance of one over the others and also need to be a mechanism to reinforce the fulfillment of the assigned task.

As long as the functionality does not get compromised we are willing to implement all the changes that lead to decentralization.

jfdelgad commented 5 years ago

I have come to a draft of a solution based on the design of an adjudicator. This is a smart contract that determines if an executor can or not execute a particular transaction. This makes the assignation organized and avoid competition for executing a task in a fair fashion. Some questions remain:

The maximum number of executors. A limit should be imposed so that the executors can actually profit, having hundreds of executors make the activity low to profit unless the systems have hundreds of thousands of transactions per month. I suggest limiting the executors to 10 or 20 but to leave open the option to add more in the future.

Deposit and penalties. If an executor fails to execute a transaction, any other executor can take over after a certain number of blocks (20 blocks) and get the fee and the gas reimbursement. However, the misbehaving executor that missed the transaction should have something to lose if not the system can be subject to attacks from malicious actors. Yet, the penalty should not be strong as it is possible that the transactions do not go through by several reasons, a penalty equal to the fee or a percentage of the transaction fee will suffice. This means that the executors should deposit some funds to become executors, this can be reclaimed at any time that the executor decides to leave the system.

Executors (for each transaction executed) are reimbursed the gas plus the fee, ETHPantheon as the creator will expect something, I suggest that the executors get the 90%-95% of the fee and the remaining 10%-5% goes to ETHPantheon

The adjudicator should control the fee value. Aion already controls that the fee cannot be increased arbitrarily but these possible changes should be controlled by the adjudicator. The simplest thing would be to lead this under the control of ETHPantheon, high fees will discourage the users from using the system while low fees will discourage the executors. As the number of transaction per month rise, the fee value should decrease.

I will have this implemented soon and we can deploy a copy of Aion on Rinkeby for testing after testing it locally.

mudgen commented 4 years ago

This is interesting, what is the status of this?

jfdelgad commented 4 years ago

This is interesting, what is the status of this?

I had a draft of this, but there are some issues to handle. In particular, the asignation of the validators when one of them leave the smart contract is problematic, I figure out that using a linked list may solve the issue but I have not worked on this for the last few months. Let me know if you are interested.