Abstract

A vanilla non-fungible token standard proposed by CIP-82 combined with the established unicode system can create an on-chain logographic system for representing language characters that are logographs. Examples include hanzi in Mandarin, kanji in Japanese, hanja in Korean, and etc.

Motivation

A logograph is a written character that represents a word or morpheme, whereas a unicode is an information technology standard for the consistent encoding, representation, and handling of texts. A vanilla NFT by CIP-82 can naturally combine the two into a new system that is ideal for on-chain representation of logograpic language systems.

It is valuable to build this system for logographs because a rich amount of meanings can be transmitted in just a few tokens. However, this is not providing additional utility compared with existing messaging systems for non-logographic languages such as English. Emojis can be universally accepted.

Examples

Instead of sending the Chinese letters of the Great Wall 长城, two CIP-82 tokens with ID#38271 and ID#22478 are sent in order to represent the two letters. The receiving end decodes the IDs and retrieves the original logographic characters.

Applications

On-chain chatting, blogs, micro-blogs systems can be built for communities using these languages. Centralized censorship can be much improved with systems built upon this standard.

Conflux utilizes a storage model that is based on a key-value database. The contract deletion process relies on the storage layer's interface named delete_all_by_prefix to clear the storage and the whitelist for this contract.

Conflux's storage consists of three main parts: Snapshot, intermediate set, and delta set. The key serialization logic for the last two sets differs from the snapshot, as elaborated in the Conflux Protocol Specification Sections 3.2.1 and 3.2.2.

There is a bug in the implementation. While the delete_all_by_prefix logic can accurately process data in the Snapshot, it fails to do so for the data in the intermediate and delta sets. This discrepancy leads to a specific issue: When attempting to kill a contract, whitelist entries written in the most recent 2000 to 4000 epochs (the most recent two snapshot periods) might not be correctly removed.

The Ethereum community is actively pushing to eliminate the SELFDESTRUCT(0xff) opcode (e.g., EIP-4758, EIP-6780). Deploying a new contract at the same address as a self-destructed contract is a rare and unusual behavior resulting from the SELFDESTRUCT(0xff) opcode. Conflux's sponsor mechanism should not make special accommodations for such corner cases. Instead, when a contract is deleted, its whitelist should be retained. If a new contract is subsequently deployed at the same address, the deployer and sponsors of the new contract should rightfully inherit the whitelist of the previous contract at that address.

1. Return value of estimateGasAndCollateral

Before the change

Revert without reason

{code: -32015, code: "Estimation isn't accurate: transaction is reverted. Execution output ", data: "0x..."}

Revert with reason

{code: -32015, code: "Estimation isn't accurate: transaction is reverted. Execution output Reason provided by the contract: 'ERC20: transfer amount exceeds allowance'", data: "0x..."}

After the change

Revert with reason

{code: -32015, code: "Estimation isn't accurate: transaction is reverted: ERC20: transfer amount exceeds allowance.", data: "0x..."}

Revert without reason, but a sub-call provides a reason.

For example, a contract calls USDT_contract.transferFrom(from, to, value). The function transferFrom will be reverted with reason 'ERC20: transfer amount exceeds allowance'. But the outside function will revert without reason.

{code: -32015, code: "Estimation isn't accurate: transaction is reverted. Innermost error is at cfx:type.contract:achc8nxj7r451c223m18w2dwjnmhkd6rxawrvkvsy2: ERC20: transfer amount exceeds allowance.", data: "0x..."}

Here, cfx:type.contract:achc8nxj7r451c223m18w2dwjnmhkd6rxawrvkvsy2 is the contract address of USDT.

Revert without reason, and a sub-call also provides no reason.

{code: -32015, code: "Estimation isn't accurate: transaction is reverted.", data: "0x..."}

Revert with reason, and a sub-call also gives a reason.

For example, when your contract calls USDT contract via safeTransferFrom function provided by OpenZeppelin, then the USDT contract will revert with reason "ERC20: transfer amount exceeds allowance" and your contract will revert with reason "SafeERC20: low-level call failed".

{code: -32015, code: "Estimation isn't accurate: transaction is reverted: SafeERC20: low-level call failed. Innermost error is at cfx:type.contract:achc8nxj7r451c223m18w2dwjnmhkd6rxawrvkvsy2: ERC20: transfer amount exceeds allowance.", data: "0x..."}

2. Error message in receipt

The error message when a transaction is reverted changes.

Before the change.

"Vm reverted, Reason provided by the contract: 'ERC20: transfer amount exceeds allowance'"

After the change.

"Vm reverted, ERC20: transfer amount exceeds allowance"

3. Trace

The trace of a transaction is a list of actions. If an action is a call result or a create result, it will contain a key called returnData.

Before the change.

If the outcome of call/create result is fail, the returnData must be empty.

After the change.

If the outcome of call/create result is fail, the returnData is a hex encoded string of error message.

The following CIPs are discussing add additional precompiled functions:

• CIP 44: Introduce VDF Verification Builtin. link
• CIP 51: Support SM-2/3 verification as internal contracts. link

With a CIP index it will be easy to find a specify one

Ref #109

As the ZKrollup and on-chain privacy attract a lot of attentions and have massive application perspectives, we should consider adding the neccessary built-in functions, including

• File storage. (Stores the customized ZK verification key, in size of megabytes.)
• Basic operations for different elliptic curves.
• Artimetic circuit friendly cryptographic primitives, such as Poseidon hash function.
• Special data structure, e.g. Commitments with simple membership proof (Merkle Tree).

The most convenient API way is to provide an internal contract interface.

Previous discussion: #64.

Recently we upgraded serveral Nodes, found it may take 1~4 hours to catch up the latest state(Aliyun cloud server located in HK).

If our server stopped unexpectedly, we may take 10 miniutes to receive the alert, 30 minutes to work status, 3 hours sync to latest state, 3 hours 40 minutes in total.

Hope can extend to 6 hours, otherwise we have to prepare a backup server to handle it.

A recent PR changes the trace of transaction trace. The changes are described as follows.

中文摘要

• trace 列表的每个 item 增加一个 field "valid". "valid" 为 false 时表示该条 trace 因为 revert 等原因没有改变 state.
• Gas 费用的收取和存储押金的收取、退还将产生 trace. 类型为 "internal_transfer_action".
• Type 为 ”internal_transfer_action“ 的 trace 项添加两个 field, "fromPocket" 和 "toPocket". 只有当 "fromPocket" 等于 "balance" 时，才意味着 "from" 的余额被修改。

The "valid" field

If the inner message call triggers an error and the error is caught by the outside contract, the whole transaction could also succeed, but the effects of the inner message call are reverted. The traces of the reverted message call will also be retained for debugging usage.

Here, we add a new field "valid" to indicate whether the corresponding trace is reverted.

Trace for gas payment.

Any transaction bumping nonce during execution will generate one or two traces with type "internal_transfer_action" to indicate gas payment and gas refund.

Consider a transaction has gas limit 40000 and gas price 3 Drip.

For gas payment, if the transaction is sponsored, the trace will be

{
    "action": {
        "from": <contract_address>,
        "fromPocket": "sponsor_balance_for_gas",
        "to": <zero_address>,
        "toPocket": "gas_payment",
        "value": 120000, 
    }
    "type": "internal_transfer_action"
    ......
}

If the transaction is not sponsored, the trace will be

{
    "action": {
        "from": <sender_address>,
        "fromPocket": "balance",
        "to": <zero_address>,
        "toPocket": "gas_payment",
        "value": 120000, 
    }
    "type": "internal_transfer_action"
    ......
}

This should be the first trace of most transactions.

After execution, if this transaction costs 25000 gas, up to 1/4 of gas limit, i.e., 10000 gas (30000 Drip when gas price = 3) will be refunded, then it will generate a trace

{
    "action": {
        "from": <zero_address>,
        "fromPocket": "gas_payment",
        "to": ...,
        "toPocket": ...,
        "value": 30000, 
    },
    "type": "internal_transfer_action",
    ...
}

Trace for storage collateral.

Consider a transaction collateralize 10 Drip (it can not happen in a real Conflux system, just for example).

If the transaction is sponsored,

{
    "action": {
        "from": <contract_address>,
        "fromPocket": "sponsor_balance_for_collateral",
        "to": <contract_address>,
        "toPocket": "storage_collateral",
        "value": 10, 
    },
    "type": "internal_transfer_action",
    ...
}

If the transaction is not sponsored,

{
    "action": {
        "from": <sender_address>,
        "fromPocket": "balance",
        "to": <sender_address>,
        "toPocket": "storage_collateral",
        "value": 10, 
    },
    "type": "internal_transfer_action",
    ...
}

When releasing storage, the value will be returned to the same route.

Changes in the sponsorship (example)

When a user adds sponsor balance for gas for a contract, the trace will be

Before change

{
    "action": {
        "from": <sender_address>,
        "to": <internal_contract_for_sponsorship>, // 0x088800...01
        "value": ...,
        ...
    },
    "type": "call",
    ...
}

After change

{
    "action": {
         // call type trace has no fromPocket and toPocket field. Because the pocket is always "balance". 
        "from": <sender_address>,
        "to": <internal_contract_for_sponsorship>, // 0x088800...01
        "value": ...,
        ...
    },
    "type": "call",
    ...
}
{
    "action": {
        "from": <internal_contract_for_sponsorship>, // 0x088800...01
        "fromPocket": "balance",
        "to": <contract_address>,
        "toPocket": "sponsor_balance_for_gas"
        "value": ...,
        ...
    },
    "type": "internal_transfer_action",
    ...
}

Now you can know which contract is sponsored from the trace.

Changes in the staking (example)

When a user stakes, the trace will be

Before change

{
    "action": {
        "from": <sender_address>,
        "to": <internal_contract_for_staking>, // 0x088800...02
        "value": ...,
        ...
    },
    "type": "internal_transfer_action",
    ...
}

After change

{
    "action": {
        "from": <sender_address>,
        "fromPocket": "balance",
        "to": <sender_address>, 
        "toPocket": "staking_balance",
        "value": ...,
        ...
    },
    "type": "internal_transfer_action",
    ...
}

Indicator for kill contract

Each time a contract is killed, it will produce such a trace,

{
    "action": {
        "from": <contract_address>,
        "fromPocket": "balance",
        "to": <zero_address>, 
        "toPocket": "mint_burn",
        "value": ...,
        ...
    },
    "type": "internal_transfer_action",
    ...
}

Changes in integrity constraints

Before change

• The balance increasing (or decreasing) of an address (except the internal contract) during transaction execution corresponds to a trace whose "to" (or "from") is this address.

After change

• The balance increasing (or decreasing) of an address (all the address) during transaction execution corresponds to a trace whose "to" (or "from") is this address and "toPocket" (or "fromPocket") is "balance". (Note: for trace type except "interal_transfer_action", the "fromPocket" and "toPocket" equal to "balance" implicitly.)
• The staking balance/collateral balance/sponsor balance for gas/sponsor balance for collateral increasing (or decreasing) of an address during transaction execution corresponds to an internal_transfer type trace whose "to" (or "from") is this address and "toPocket" (or "fromPocket") is "sponsor_balance"/"storage_collateral"/"sponsor_balance_for_gas"/"sponsor_balance_for_collateral".

Specification for pocket

In Conflux, each account could have several pockets to store CFX.

• balance
• staking_balance
• storage_collateral
• sponsor_balance_for_gas
• sponsor_balance_for_collateral

The fromPocket field and toPocket field could be one of them.

Besides these five values, the "pocket" could be two special values "mint_burn" and "gas_payment".

• fromPocket = "mint_burn": mint CFX, e.g., generate staking interest
• toPocket = "mint_burn": burn CFX, e.g., when a contract is killed, its staking balance will be burnt.
• fromPocket = "gas_payment": gas payment, usually equals to gas_price * gas_limit
• toPocket = "gas_payment": gas refund after transaction execution.

A vanilla NFT standard is proposed. In this standard, a non-fungible token stands as atomic existence and can be understood as an ERC721 token having data fields and functions related to URI removed. This standard encourages layers of abstraction built on top of NFTs. Ideal for representing concepts like right, a form of abstract ownership. Such right, especially on-chain right, can then be made liquid because of this tokenization.

An example of applying this token to represent the right of making a function call to a contract is given here.

An on-chain subscription business model is also made possibe by adopting this token to represent quarterly or yearly membership (time-dependent right). An example can be fees per transaction for off-chain data via an oracle can be replaced by a long-term membership fee. Then as long as the caller has a valid CIP-82 NFT, the consumption of data feeds is free (plus gas fees). NFTs can be transferred, so is the right of consuming data feeds. This definitely has great advantages over the current pay-as-you-go business model.

Another great illustration of this concept can be found in this tweet that Andre Cronje sold the naming rights to his Twitter account to FTX.

Motivations

Ethereum's community is discussing the account abstraction, which enables the users to

create 'account contracts' that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.

They also provides several cases which can benefit from this feature in EIP-86

• Multisig wallets: currently, sending from a multisig wallet requires each operation to be ratified by the participants, and each ratification is a transaction. This could be simplified by having one ratification transaction include signatures from the other participants, but even still it introduces complexity because the participants' accounts all need to be stocked up with ETH. With this EIP, it will be possible to just have the contract store the ETH, send a transaction containing all signatures to the contract directly, and the contract can pay the fees.
• Ring signature mixers: the way that ring signature mixers work is that N individuals send 1 coin into a contract, and then use a linkable ring signature to withdraw 1 coin later on. The linkable ring signature ensures that the withdrawal transaction cannot be linked to the deposit, but if someone attempts to withdraw twice then those two signatures can be linked and the second one prevented. However, currently there is a privacy risk: to withdraw, you need to have coins to pay for gas, and if these coins are not properly mixed then you risk compromising your privacy. With this EIP, you can pay for gas straight our of your withdrawn coins.
• Custom cryptography: users can upgrade to ed25519 signatures, Lamport hash ladder signatures or whatever other scheme they want on their own terms; they do not need to stick with ECDSA.
• Non-cryptographic modifications: users can require transactions to have expiry times (this being standard would allow old empty/dust accounts to be flushed from the state securely), use k-parallelizable nonces (a scheme that allows transactions to be confirmed slightly out-of-order, reducing inter-transaction dependence), or make other modifications.

and in EIP-2938.

1. Smart contract wallets that use signature verification other than ECDSA (eg. Schnorr, BLS, post-quantum...)
2. Smart contract wallets that include features such as multisig verification or social recovery, reducing the highly prevalent risk of funds being lost or stolen
3. Privacy-preserving systems like tornado.cash
4. Attempts to improve gas efficiency of DeFi protocols by preventing transactions that don't satisfy high-level conditions (eg. existence of a matching order) from being included on chain
5. Users being able to pay for transaction fees in a token other than ETH (eg. by converting that token into the ETH needed for fees inside the transaction in real-time)

Besides that, there is another important case for Conflux

• Sign Conflux transactions by Metamask: If a message signed by Metamask can be accepted as a valid transaction on the mainnet of Conflux, the user can do almost everything on Conflux without installing. This can reduce the barrier to experience Conflux.

Why Conflux can have a better solution than Ethereum?

In EIP-2938, Ethereum community provides a complicated solution to implement account abstraction, which includes two addtional opcode and the gas price/gas limit can be changed during transaction execution. This makes the transaction packing logic much more complicated.

Fortunately, Conflux has sponsorship mechanism, which enables a more elegant solution for account abstraction. Even without any upgrade, Conflux can still support some use cases in account abstraction.

For example, consider the cUSDT token contract want to support account controlled by ed25519 public keys. The contract developer can implement a function called submitEd25519TransactionWithSign(address sender, address receiver, uint value, bytes signature) and sponsor for all the addresses. A user can use a normal Conflux address to call this function and submit ed25519 signature. Benefit from the sponsorship mechanism, it is not necessary that the sender has CFX tokens. So the sender can generate a random string as private key, sign the transaction and send it.

What to do next?

This example still has several drawbacks.

1. Since it doesn't matter who is the sender, it is not neccessary to verify the ECDSA signature for such transaction. This wasted about 6000 gas.
2. The attacker may run out the sponsor balance by submitting invalid signature.
3. The supporting for ed25519 must be implemented by the contract developer. The ed25519 account can not act like a normal account in Conflux Network.

So, we have the following CIPs:

• CIP-45: Introduce Flexible Account Authorization Methods. This CIP proposes to support SECP-256k1 directly.
• CIP-52: Customized Rule for Eligibility to be Sponsored. This CIP proposed to allow the contract developer to specify a short script to check if the sender can be sponsored. All the miners should avoid packing. In the implementation view, we need to replace checking whitelist by running short script. (We also needs some design for backward compatible.) This CIP can support all the use cases in EIP-2938 and solve the second drawbacks in our example. A side effect for this CIP is this enables the contract developer customize the sponsorship rule. E.g., only the addressed staked enough contract token can be sponsored.
• TBA, a CIP for drawback 3.

Motivation：Avoid the use of Ethereum and conflux addresses misdirection

scheme：

1. Wrapper current hex address to base58 format like TRON
2. Maybe let conflux support the base58 and hex format or only one format.

The index of new CIPs should start with two. This issue occupies index one of issues and PRs.

Previous discussion: #34.

1. Do we require a minimal voting power? Or do we allow a faster update if the voting is unanimous?
2. Do we need an option to vote for unchange or just let the user to distribute the votes for both increase and decrease?
3. Do we want new votes to override old votes or do we want every vote to be final?
4. Do we need to store the vote data in a way that they can be garbage collected after each vote period?
5. Do we need separate interfaces to vote for one or multiple parameters?

It's a good idea to burn storage collateral when defunding to mitigate inflation of CFX tokens. However, rationale details are currently missed for CIP-107. For example,

• The estimation of the transaction fee growth. This is important for developers and users.
• The estimation of the inflation rate change. This can guide DAO to decided p.
• Why the minimal p but not zero is choosen as 0.25, and won't this value greatly increase the transaction fee?

I hope these details could be added to the next version of CIP-107

Because hardfork 2.3.0 will launch in 9.8, so the related CIPs should update their status after 9.8 @ChenxingLi