Insufficient Enerngy

  • Home

  • Archives

Fee Delegation-MPP

Posted on 2019-08-13 | Edited on 2019-08-14

Before we start, let’s clarify some concepts:

TxOrigin: the sender of transactions, an externally owned account.
GasPayer: the account pays the transaction fee.
Fee Delegation: transaction fee delegation(paid by a third-party), usually refers to the situation where the transaction fee is not paid by TxOrigin.
Multi Party Payment: Multi-party Payment Protocol, a type of Fee Delegation.

The Story

We had experience in developing on Ethereum, and we figured a core problem to be tackled. People had difficulties in accepting the fact that applications/tokens need to be funded by ETH as transaction fee. In other words, it was not an easy task to promote blockchain applications, and it was even harder to have the users try out the applications for the first time. Therefore, we published the prototype-based transaction fee delegation protocol to lower the cost of using the blockchain application for users.

Read more »

Fee Delegation-VIP191

Posted on 2019-08-13 | Edited on 2019-08-14

In the previous article Fee Delegation-MPP, I introduced MPP, the prototype-based transaction fee delegation protocol. I also mentioned that it cannot meet the needs of developers in several circumstances. Noticeably, Totient Labs combined multiple contracts in one transaction when developing CometVerse, and they also wished to pay transaction fees for the users. Therefore, Totient Labs brought up VIP-191 to extend the transaction fee delegation protocol.

Content

VIP-191 was proposed to extend the fee delegation protocol and to further explore its application scenarios, so as to make up for situations not covered by MPP. It includes:

  1. Extending the TX model by adding Delegator signature.
  2. Identifying VIP-191 enabled Txs by setting Fee Delegated true.
Read more »

Fee Delegation - VIP191(中文版)

Posted on 2019-06-05 | Edited on 2019-08-14

在上一篇 Fee Delegation - MPP(中文版) 中,介绍了 MPP - 基于账户原型的交易费用代付协议 也提到了它在某些情况下是无法满足开发者需求的。尤其是 Totient Labs 在开发应用 CometVerse 的时候组合了多个合约又希望可以为用户付交易费,所以 Totient Labs 提出了 VIP-191 来扩展费用代付协议。

VIP-191 的内容

VIP-191 的提出是为了扩展费用代付协议,扩展它的应用场景来弥补原有 MPP 无法覆盖到的情况。 它主要包含以下方面:

  1. 扩展交易模型,加入 Delegator 签名
  2. 扩展交易模型, 加入 Fee Delegated Flag 明确交易仅在它设置为 true 的情况下才是 VIP-191 代付的交易
Read more »

Fee Delegation - MPP(中文版)

Posted on 2019-05-25 | Edited on 2019-08-14

在开始之前,我们先描述几个概念:

TxOrigin: 交易发起方,一个外部账户(私钥控制的账户)
GasPayer: 支付交易费用的账户
Fee Delegation: 交易费用委托(代付), 一般指交易费用不是由 TxOrigin 支付的场景
Multi Party Payment: 多方支付协议, Fee Delegation 的一种形式

起源

我们之前有一段在以太坊上面开发的经验,我们发现向大众推广区块链应有会有一个核心问题需解决,用户对于需要ETH来为应用/代币支付手续费这件事情的接受有一定的困难,换句话说区块链应用向用户推广的难度偏高,想要获取用户的首次点击尝试变得相当困难。所以我们提出了基于账户原型的交易费用代付协议,来降低终端用户使用区块链应用的成本。

Read more »

Gas Estimation

Posted on 2019-05-20 | Edited on 2019-08-14

Gas is an unit that measures the transaction cost in EVM ecosystem. It is well known that transfers native coin(e.g. VET, ETH) needs 21000 gas to cover the transaction fee, but regarding the contract creation and execution, the gas cost is not a fixed value. The gas cost depends on the state on which executed the tx, this is related with EVM’s gas consumption mechanism. One transaction packed in different block could result in different gas cost.

Transaction gas is composed with two parts, Intrinsic Gas and Runtime Gas. The Intrinsic Gas for a transaction is the amount of the transaction used before runtime executes the transaction.

intrinsicGas = txGas + SUM(clause.typeGas + clause.dataGas)

Intrinsic Gas is deterministic for an transaction while Runtime Gas is dynamic.We have a way to evaluate a transaction’s Runtime Gas by the API POST /accounts/*. As stated above, the evaluated gas just based on the current BestBlock's State. The gas cost may change when you send the same transaction to the blockchain with the evaluated gas. So the trick is:

You need to increase the evaluated gas before add it to tx gas.

Read more »

Watch The Blockchain

Posted on 2019-05-16 | Edited on 2019-08-14

Introduction

Blockchain is a chain of block and block proposers keep proposing new blocks to it. Every new block means new status, when developing the blockchain apps, we may need to “watch” the blockchain then we know that is the time to update the status. I will show you the trick of watching the blockchain by Connex.

Ticker

Ticker is an API from Connex. In the doc, it is described as following:

Ticker is a concept that describes chain increment, when there is a new block added to the chain, tickers will be triggered. This API will create a ticker which has a function that creates a Promise that will resolve when a new block is truly added, please be advised that it never rejects.

Ticker will make it possible for apps to be notified once there is new state on the blockchain.

Read more »

tony.li

6 posts
15 tags
0%
© 2019 tony.li
Powered by Hexo
|
Theme – NexT.Gemini