-
Notifications
You must be signed in to change notification settings - Fork 7
Reddit point on ALD
This document provides potential design to have a more trust-less reddit point system leveraging the ALD (abstract layer design) of the plasma framework on OMG network. For more details on ALD documents, please refer to the integration doc and some other design explanations.
By analyzing the original community point contracts and its description, we would need some of the following states to be able to be described in our layer 2 system:
- Total available point per distribution round
- Total Karma per distribution round
- Root chain timestamp for a child chain block number: we need relative time for subsciption
We will be going to have the followings new outputs for user to own and transfer:
- Karma
- Community Point
- Subscription
All of them would be with special output type instead of reusing the output type used for ERC20 transfer. The reason is that we would like to restrict the usage of those output to specific tx type that has the customized rules. Note that in this design, we would need 2 output types for community point while only 1 output type is need for Karma and 1 for subscription. The reason of having 2 output types for community point is to differentiate the output minted and owned by the oracle service and the output already transferred to the user. This allow restriction on the claim tx to follow the claim business logic and release the restriction on the normal transfer transaction of the community point. For transfer, we can reuse the same output type as normal ERC20 transfer would do. We do not need multiple types for Karma and subscription as so far Karma would be only consumed in the claim tx and subscription being an output generated for reference. How the subscription service provider is aiming to use the subscription is out of the scope of this design doc.
We would like to have state to represent the Karma earned by the users. User could use the earned Karma to claim their community points. Since the Karma <> Community point exchange rate differs on each distribution round, aside from the normal ERC20 token output data, it also need to reference the distribution round. As a result, the output data structure of Karma would be like:
- output type
- owner
- token
- amount
- distribution round
For Community Point it is quite simple and standard. It will be using the same data format as our normal ERC20 output that includes the following data:
- output type
- owner
- token
- amount
One of the requirement of subscription is to have a expiration date. As a result, it would need to have a reference expiration date in subscription output. We are aiming the granularity to the level of day. Also, we would like to ensure that the subscription service provider (subscription manager) has recognize the subscription, we need the subscription manager address in the subscription output as well to be able to check the signature.
- output type
- subscription manager address (to make things simple, we will assume it is some sort of subscription provided by community point platform and reuse community Points oracle service oracle service address for this)
- subscriber
- expiration date
- Community Points platform: a platform where the Community Points systems is being hosted, such as Reddit.
- User: the normal reddit user
- Community Points oracle service: the service that can sign off the global state in L2. However, it has to follow the ALD restricted transaction rules. So it is just an oracle that is acting as a global state viewer, checker, and provider.
Most actions will be represented by atomic swap of fungible tokens with some addition rules using the new states from layer 1. The following doc would assumes the new transaction follows Generic Transaction format of ALD.
We will have a new tx type for the claim tx.
The claim tx need the following inputs:
- Karma points owned by the user
- Community points owned by community points oracle service with the special output type
- OMG network fee input
Also with the following outputs:
- Karma points transferred to a burning address
- Community points transferred to the user using normal ERC20 output type
In the txData part, it should reference to that L1 state being "deposit"-ed:
- Total available point per distribution round
- Total Karma per distribution round
A valid claim tx should have the tx signed by the Karma point owner (User), community point owner (community points oracle service) and the fee input owner. The claim tx type has the rule of it should follow the distributed rate. The input Karma and the exchanged community point should be following the rate decided by the total available point and total Karma. The tx should be referencing to the data of the exact same round number in the Karma input. Watcher would report byzantine events if there exist the tx that does not follow the distributed rate of karma <> community point.
This would same as normal ERC20. User can transfer the received community points.
Note that the user can create a transfer to update the inclusion timestamp of the community point output. This can make his/her subscription starting with a latest date. See the following Subscribe section for more detail.
We will also have a new tx type for the subscription tx.
The subscription tx would have the following inputs:
- community point owned by the user
It would have the following outputs:
- community point transferred to a burning address
- subscription token transferred to the user, with an expiration date (to the granularity of day)
The txData should include a root chain "time" that link to child chain blknum that is equal or less than the blknum of the community point input. That would be act as the subscription start date. Since the granularity is to the level of day, the user can submit a transfer transaction to the user him/herself first to bump the community point inclusion date and then refer to the latest root chain "time".
A valid subscription tx should have the tx signed by the community point owner, the community point oracle service (acting subscription manager). As for implementation, we could let the spending condition of the community point input to check both signatures.
We will be using a specific burning contract to collect all the burned tokens. A life cycle of burning for a fund would be the token is first transferred to the burning address which is the burning contract's address. The burning contract can start standard exit from OMG network to exit the fund to the burning contract. Once exited, the fund would be locked inside that burning contract. The burning contract would expose the total finalized burned amount inside the contract.
Same as the original distribution logic, the community point would be minted on Layer 1 when advancedToNexRound is called. We will have a specific vault and transaction type for the community point platform to "deposit" those minted tokens. Those deposited token via this special vault would have to be with a special output type for the community point output. This specific output type can only be spent in the claim tx and not the transfer tx. The claim tx would have the check of the claiming logic. This is to ensure a trustless claiming with efficient migration from Layer 1 to Layer 2 that still takes the claiming logic into effect.
There is an issue calculating the burned tokens in Layer 2 system. To finalize the the "burn" state back to layer 1, it would need 2 weeks to finalize that. As a result, it might not be practical to reflect the burned token amount right in the next distribution. However, we could have the burned token being reflected in the N + 2 round. So we have a specific burning contract (used as the burning address above). This burning contract will "exit" the burned token to lock into the contract but provide the total burned amount for the distribution contract to read from later in N+2 round.
In the earlier of the doc, it mentioned that we have some global states that need to be injected into layer 2. To enable this, we would need new vault to support "deposit" those states as an output in the OMG network. By deposit it means to inject the sate from layer 1 to layer 2. The data correctness would be directly verified in L1 contract (Vault contract). Anyone should be able to act as the oracle to inject those global states from L1 to L2.
We will have new transaction types and output types to hold these new global states. After injected, this data would be referenced in other txs' txData field. Unlike other outputs, these kind of output is not there to be spent.
The global state should be injected to L2 periodically.
- Total available point per distribution round: this should be inject to L2 on each distribution round. (suppose to be 4 weeks)
- Total Karma per distribution round: same as above, this suppose to be injected to L2 on each distribution round.
- Root chain timestamp for a child chain block number: we might want to do this daily so we can have a reference point to the granularity of level of day.