
Telegram Mini Apps电报小程序开发文档
2022年4月Telegram的MiniApp(之前为Web App,6.0版后改名为Mini App)上线,Mini Apps(简称 TMAs,中文名:小程序)很可能会变成一个类似于微信小程序的平台,使得Telegram 更接近一个“超级应用”。目前,电报小程序推出不久,版本还在快速迭代中,开发人员也较少,但电报庞大的用户群基础很可能会产生大量的小程序。 作为Web3的开发者,大多数应用都是前端和区块链直接交互,但电报bot只支持消息通过电报服务和bot所在的服务器进行交互,导致大量DAPP无法给到用户可靠的账户安全保障。电报小程序在电报应用中“嵌入”了Web前端应用,通过它与区块链和智能合约直接交互,将账户信息通过安全策略在本地进行保存,大幅度提高账户安全性。同时,将与区块链无关的业务逻辑通过bot与服务器进行交互,提高用户体验。 所以,Telegram+小程序+bot+智能合约的开发模式,可能会称为一种全新的Web3开发技术栈。事实上,从时间上看,电报小程序与TON链同时推出,也可能有这方面的用意。但是这种开发模式不仅仅适用于电报和TON链,更适用于用户量庞大的各种EVM链...

使用Session Key委托服务器安全的操作抽象账户
最近电报自动交易机器人和各种SocialFi很火,这些产品给用户带来了类似Web2的良好用户体验。但火爆的背后,也发生了多起安全事件。为此,很多新上线的平台开始使用更先进的账户安全技术来保护用户资产,比如@tomo_social使用了ERC-4337账户抽象技术,有些电报机器人采用了MPC钱包技术。 尽管账户抽象钱包(AA钱包)已经具备了零gas费(服务商代付gas费),多签,社交登录等强大功能,并大幅度提升用户体验,但是因为ERC-4337属于在现有以太坊共识基础上的补丁方案,与链交互签名时仍旧需要私钥,各种方案只是在私钥保存和签名环节采取各种安全措施。 所以,虽然很多代用户签名交互的电报机器人,SocialFi平台通过MPC钱包或AA钱包来保障客户的私钥安全,但实际上,因为最终还是要通过钱包主私钥来进行签名,本质上还是私钥的验证模式,所以仍旧有私钥泄露的风险。 今天看到AA钱包创新项目ZeroDev的Session Key(对话密钥)解决方案,可以让AA钱包授权生成一个或若干个Session Key(也是一种私钥),来受控的执行经授权的操作。这种授权模式有别于ERC-20或E...
FERC20:一个更公平的ERC20方案
简介我们非常高兴地宣布,erc20.cash 上线了。这是一个更公平的的ERC20代币方案,我们将它命名为:Fair ERC-20,简称FERC20。 今年3月8日,BRC20代币在比特币链上通过Ordinals部署成功,在短短一两个月内吸引了大量关注和资金的参与。BRC20代币的成功得益于以下几个原因:简洁的Ordinals协议使得BRC20发行方无法在代币上做过多的编程,避免了在以太坊合约中各种安全风险和一些自私的设计。人人平等的铸币权。BRC20的发行方或项目团队,无法像在以太坊智能合约中通常做的那样,给自己或相关利益方预留一部分免费(低价)代币。在铸造BRC20时,所有人都站在同一起跑线上,即使发行方和团队也是如此。比特币的UTXO机制和低性能,让很多具有速度优势的智能合约机器人无法在比特币网络上工作,从而防止了通过技术手段获得比正常参与者更大的优势以及由此造成的不公平。上述原因使得BRC20对社区参与者来说,更公平,从而吸引了更多人参与。 但是,即使如此,有个非常有意思的现象是:大多数以太坊社区的成员尚未参与BRC20。 所以,我们想,是否能将BRC20的公平发售(Fa...



Telegram Mini Apps电报小程序开发文档
2022年4月Telegram的MiniApp(之前为Web App,6.0版后改名为Mini App)上线,Mini Apps(简称 TMAs,中文名:小程序)很可能会变成一个类似于微信小程序的平台,使得Telegram 更接近一个“超级应用”。目前,电报小程序推出不久,版本还在快速迭代中,开发人员也较少,但电报庞大的用户群基础很可能会产生大量的小程序。 作为Web3的开发者,大多数应用都是前端和区块链直接交互,但电报bot只支持消息通过电报服务和bot所在的服务器进行交互,导致大量DAPP无法给到用户可靠的账户安全保障。电报小程序在电报应用中“嵌入”了Web前端应用,通过它与区块链和智能合约直接交互,将账户信息通过安全策略在本地进行保存,大幅度提高账户安全性。同时,将与区块链无关的业务逻辑通过bot与服务器进行交互,提高用户体验。 所以,Telegram+小程序+bot+智能合约的开发模式,可能会称为一种全新的Web3开发技术栈。事实上,从时间上看,电报小程序与TON链同时推出,也可能有这方面的用意。但是这种开发模式不仅仅适用于电报和TON链,更适用于用户量庞大的各种EVM链...

使用Session Key委托服务器安全的操作抽象账户
最近电报自动交易机器人和各种SocialFi很火,这些产品给用户带来了类似Web2的良好用户体验。但火爆的背后,也发生了多起安全事件。为此,很多新上线的平台开始使用更先进的账户安全技术来保护用户资产,比如@tomo_social使用了ERC-4337账户抽象技术,有些电报机器人采用了MPC钱包技术。 尽管账户抽象钱包(AA钱包)已经具备了零gas费(服务商代付gas费),多签,社交登录等强大功能,并大幅度提升用户体验,但是因为ERC-4337属于在现有以太坊共识基础上的补丁方案,与链交互签名时仍旧需要私钥,各种方案只是在私钥保存和签名环节采取各种安全措施。 所以,虽然很多代用户签名交互的电报机器人,SocialFi平台通过MPC钱包或AA钱包来保障客户的私钥安全,但实际上,因为最终还是要通过钱包主私钥来进行签名,本质上还是私钥的验证模式,所以仍旧有私钥泄露的风险。 今天看到AA钱包创新项目ZeroDev的Session Key(对话密钥)解决方案,可以让AA钱包授权生成一个或若干个Session Key(也是一种私钥),来受控的执行经授权的操作。这种授权模式有别于ERC-20或E...
FERC20:一个更公平的ERC20方案
简介我们非常高兴地宣布,erc20.cash 上线了。这是一个更公平的的ERC20代币方案,我们将它命名为:Fair ERC-20,简称FERC20。 今年3月8日,BRC20代币在比特币链上通过Ordinals部署成功,在短短一两个月内吸引了大量关注和资金的参与。BRC20代币的成功得益于以下几个原因:简洁的Ordinals协议使得BRC20发行方无法在代币上做过多的编程,避免了在以太坊合约中各种安全风险和一些自私的设计。人人平等的铸币权。BRC20的发行方或项目团队,无法像在以太坊智能合约中通常做的那样,给自己或相关利益方预留一部分免费(低价)代币。在铸造BRC20时,所有人都站在同一起跑线上,即使发行方和团队也是如此。比特币的UTXO机制和低性能,让很多具有速度优势的智能合约机器人无法在比特币网络上工作,从而防止了通过技术手段获得比正常参与者更大的优势以及由此造成的不公平。上述原因使得BRC20对社区参与者来说,更公平,从而吸引了更多人参与。 但是,即使如此,有个非常有意思的现象是:大多数以太坊社区的成员尚未参与BRC20。 所以,我们想,是否能将BRC20的公平发售(Fa...
Share Dialog
Share Dialog

Subscribe to jackygu's blog

Subscribe to jackygu's blog
关于FERC V3平台发行代币过程中涉及的较多关心的问题,做如下解释:
合约中使用_mint()方法实现铸币,并通过maxRollups来控制总量。
铸造(mint)方式与一次性发放全部数量到某个地址的发放(issue)方式的不同之处在于:
铸造(mint)方式:
铸币人(或称受益人)主动触发智能合约的mint方法,从0x0地址发送代币至受益人地址(或其指定的地址)。对于无owner权限的合约,一般采取此方式。为了防止无限量铸造(增发),通常会设置一个不可更改的顶(Cap)来控制总量;
其特点有:
总量,即在区块链浏览器中会看到total supply会随着铸造进程增长,直到触及实际发行总量;
从用户角度看,币是从0x0地址发放到他们账户的;
铸造过程完全由发起铸币的人控制,不受任何第三方(包括项目方)控制;
发放(issue)方式:
一般由合约部署人(owner)主动触发mint方法,一次性将所有代币从0x0地址发送至部署人地址或其指定的收币人地址,然后由部署人转分发至其他受益人。一般这类合约会将mint方法放在合约的构造方法中在部署合约时一次性执行,也就是不允许之后再次铸造(增发)。
其特点有:
总量不变
从用户角度看,币是从部署人(或项目方)账户发放到他们账户的;
铸造过程一般会由项目方手动(或通过智能合约)操作,比如确定收到参与人一定款项后,再将币发送至参与人;
Ferc V3有免费和Fair Token Offering(FTO)两种铸币模式,前者的顶(Cap)与通常的理解无二,而对于FTO,因为部署人(Deployer)可自行设定进入流动池的Token数量,所以将无法用Cap来简单的控制总量,所以我们使用最大铸造次数(Max Rollup)来控制总量。而由此得到的实际顶(Actural Cap)通常会小于部署时设定的理论顶 Cap,之间的差额将永远无法被铸造出来。
公式如下:
Max Rollup = Math.floor(Cap * (1- Rate of token to LP) / LimitPerMint)
Actural Cap = Max Rollup * LimitPerMint / (1 - Rate of token to LP)
举例:
理论硬顶(Cap):10,000,000 个
单次铸造数量(LimitPerMint):3,000 个/次
流动性占比(TLR Rate of token to LP): 41.18%
计算结果:
Max Rollup = Math.floor(10,000,000 * (1 - 41.18%)/3,000 = 1960
Actural Cap = 1960 * 3,000 / (1 - 41.18%) = 9,996,599.80
相差:3400.2个,将永远无法铸造,占理论总量的0.034%

从上述公式可知,代币的实际发行总量(Actura Cap)由以下三个参数决定:
部署人设定的理论顶(Cap)
流动性占比(Rate of token to LP)
单次铸造数量(Limit Per Mint)
在已验证的代币合约源码中,可以看到上述三个参数均在代币构造函数中一次性设定,且代币合约无owner权限,该三项属性的不可篡改性决定了实际硬顶无法被突破。
在mint()方法中,只要通过检验maxRollups即可方便的判断是否超过实际硬顶:
function mint(address _to) payable public {
equire(totalRollups + 1 <= ferc20.maxRollups, "Touched cap");
...
}
关于FERC V3平台发行代币过程中涉及的较多关心的问题,做如下解释:
合约中使用_mint()方法实现铸币,并通过maxRollups来控制总量。
铸造(mint)方式与一次性发放全部数量到某个地址的发放(issue)方式的不同之处在于:
铸造(mint)方式:
铸币人(或称受益人)主动触发智能合约的mint方法,从0x0地址发送代币至受益人地址(或其指定的地址)。对于无owner权限的合约,一般采取此方式。为了防止无限量铸造(增发),通常会设置一个不可更改的顶(Cap)来控制总量;
其特点有:
总量,即在区块链浏览器中会看到total supply会随着铸造进程增长,直到触及实际发行总量;
从用户角度看,币是从0x0地址发放到他们账户的;
铸造过程完全由发起铸币的人控制,不受任何第三方(包括项目方)控制;
发放(issue)方式:
一般由合约部署人(owner)主动触发mint方法,一次性将所有代币从0x0地址发送至部署人地址或其指定的收币人地址,然后由部署人转分发至其他受益人。一般这类合约会将mint方法放在合约的构造方法中在部署合约时一次性执行,也就是不允许之后再次铸造(增发)。
其特点有:
总量不变
从用户角度看,币是从部署人(或项目方)账户发放到他们账户的;
铸造过程一般会由项目方手动(或通过智能合约)操作,比如确定收到参与人一定款项后,再将币发送至参与人;
Ferc V3有免费和Fair Token Offering(FTO)两种铸币模式,前者的顶(Cap)与通常的理解无二,而对于FTO,因为部署人(Deployer)可自行设定进入流动池的Token数量,所以将无法用Cap来简单的控制总量,所以我们使用最大铸造次数(Max Rollup)来控制总量。而由此得到的实际顶(Actural Cap)通常会小于部署时设定的理论顶 Cap,之间的差额将永远无法被铸造出来。
公式如下:
Max Rollup = Math.floor(Cap * (1- Rate of token to LP) / LimitPerMint)
Actural Cap = Max Rollup * LimitPerMint / (1 - Rate of token to LP)
举例:
理论硬顶(Cap):10,000,000 个
单次铸造数量(LimitPerMint):3,000 个/次
流动性占比(TLR Rate of token to LP): 41.18%
计算结果:
Max Rollup = Math.floor(10,000,000 * (1 - 41.18%)/3,000 = 1960
Actural Cap = 1960 * 3,000 / (1 - 41.18%) = 9,996,599.80
相差:3400.2个,将永远无法铸造,占理论总量的0.034%

从上述公式可知,代币的实际发行总量(Actura Cap)由以下三个参数决定:
部署人设定的理论顶(Cap)
流动性占比(Rate of token to LP)
单次铸造数量(Limit Per Mint)
在已验证的代币合约源码中,可以看到上述三个参数均在代币构造函数中一次性设定,且代币合约无owner权限,该三项属性的不可篡改性决定了实际硬顶无法被突破。
在mint()方法中,只要通过检验maxRollups即可方便的判断是否超过实际硬顶:
function mint(address _to) payable public {
equire(totalRollups + 1 <= ferc20.maxRollups, "Touched cap");
...
}
<100 subscribers
<100 subscribers
No activity yet