2301_80185446的博客

抵押型稳定币：需要中心化的东西去调节，可以抵押美元，也可以抵押以太坊。抵押以太坊这个，有可能会强制清仓。算法稳定币：可以去中心化每天去调整价格，让这个价格趋于稳定假如有100个，总价为100美元，有一天价格大于1美元一个，那他就会增加AMPL的供给，这样用户的币数量变多，又因为价格也上升了，不是1美元，就会促使更多人去购买Ampl，这样就会导致正向死亡螺旋实际上不是修改用户的真实余额，而是修改k值，修改的是用户看到的余额减少用户的心理负担。

只需要检验根节点 Merkel根是否有更改，就不用检查每个交易是否有更改。如果交易失败的话，有原子性的。但是gas费用还是要由外部账号来支付。

最终交易的就是以太坊为了控制好成本，物品价格的涨跌导致收益有变。为了这个合约生效，双方要向合约存入保证金现货，就是现在实时的价格还有一类人，在这个合约生效后，觉得这个合约在未来某个时间点会升，因此现在买入这个合约，等到未来某个时间点再卖出去，从而赚取差价。

随着时间的深入，越来越多的用户加入到挖矿当中，因为要for循环扫描各个用户来进行分配sushi币，因此会消耗很多的gas。这个流动性凭证，既可以拿回token0，token1，也可以得到分红（若有人在你的流动性池子里进行交易的操作）那我先在第二个池子兑换出2.5个b，然后把2个b还给第一个池子，那剩下的0.5个b就是我们的获利。分红是根据流动提供者占总数量的比例来给予的，因此，x y数量越多，分红越多。因为要计算扣除的手续费，且K不变，因此x 和y的数量会增加。acc：一个份额的奖励+之前的累计奖励。

1.连接钱包代码2.其他代码安装命令。

尽量填满一个槽再开一个新的槽 struct里面的也是，也要尽量占满一个槽位再下一个槽位。交易gas会被频繁调用，要着重注意。

我一开始写代码只要写白色部分的，当我需要更新的时候，我就再补充红色框就行，同时新建一个CounterWithOz2的合约。因此，为了避免槽位的冲突，我们将计算一个非常远的位置来放置这个新的东西。因为是按照槽位来锁定的，不是按照地址来锁定，所以要保证槽位的顺序相同。代理合约和逻辑合约都写好后，再写升级后的合约2。因此，逻辑合约和代理合约的变量要一致。计算逻辑合约地址的代码。

mapping(uint => uint) public tokenIdPrice uint => uint:某个tokenId对应的价格。MetadataContract：某个图片非常模糊，后面有高清图片，想替换掉原来模糊的图片，list：上架某个NFT 将某个地址的NFT转到market合约地址里面。received:做一个回调。revert掉，不给交易。永远属于我，不能被交易。

针对没有permit的代币实现的线下签名方式通过approve方法，让Permit2拿到无限次数的授权。拿到授权之后，Permit2会生成签名。当用户需要转账的时候，Permit2会发送签名给uniswap，uniswap会去Permit2去验证这个签名信息。验证完毕后，再去调用transferfrom。

目录1.EIP ERC标准 2.OpenZeppelin​3.ERC20​4.发行代币方法5. ERC授权6.ERC777 7.ERC20自写回调 callback8.ERC20的Permit 9.总结Core：链端的ERC：应用层代码： msg.sender：谁发行一个以太坊： 10 **18_mint 初始发行的代币数量先approve 才能调用deposite方法 ERC777复杂，回调多，所以若业务简单，用ERC20即可以ERC777可以传data修改状态-转账-回调 自己写一个ERC20的回调 c

解释：攻击者会在调用完call后，就执行withdraw方法，因此若有重入锁的话，第一次进入withdraw方法，locked默认为0，可以执行，然后locked变成1，当攻击者想循环进入withdraw时，因为locked一直为1，从而无法进入下一个withdraw。先将余额全部提取出来，然后将余额设置为0，这样即便call完，又想重复进入withdraw，余额都是0。B可以访问A的set()方法（即便是internal也可以），也可以拿到A的a变量。关键字时，你不需要手动传递合约地址，因为。

若require走不下去，就会回滚，x += 1 就不会实现。

目录1.可见性2.合约特殊函数 constructor && getter3. receive && fallback4.view && pure5.payable6.自定义函数修饰符 modifierpublic：内外部private：内部external：外部访问internal：内部及继承一般默认是externalconstructor：初始化逻辑 getter:所有public状态变量创建getter函数receive“接受以太币时回调fallback：没有匹配函数标识符时，fallback会

但如果是合约的话，就会消耗gas，因此，采用addr.call 可以避免gas的限制。函数通常用于那些只需要设置一次、在合约生命周期开始时就必须确定的配置。只会在合约创建时执行一次，因此它非常适合执行这些一次性的初始化任务。delegatecall可以理解为 A在调用B这个集成在A的方法。地址若是外部账号的地址，调transfer方法就没有什么问题。delegatecall：不切换上下文。绿色框：受到转账，对账户的余额进行加。黄色框：设定权限，只能被谁使用。白色框：查看账户上的余额有多少。

如果用c.count()这种方式的话，如果后续要再加新的方法，就无法自动识别了，所以用call()这种抽象的，识别abi的方式去调用。是 Solidity 中用于底层合约调用的函数，它们是智能合约之间交互的基础。方法实际上是在 ERC20 合约中定义的，它内部可能使用。是一个特定于 ERC20 代币合约的方法，用于发送代币。newCall()方法和call（）方法作用是一样的。右边的代码：拿到abi编码，然后调用call方法。在真实写代码的时候，都是用transfer。是更通用的底层调用函数，而。

同质化代币是一种能够替换、具有统一性、可接近无穷拆分的代币。例如，比特币（BTC）和以太坊（ETH）都是同质化代币。非同质化代币（Non-Fungible Token，NFT）

复制这个数字到这里，再加60s，也就是比如现在这个数字是1741784782，我就加60再改，也就是1741784842添加到红色框。再根据readme输入各种指令，每输入一个指令，在原来那个终端窗口，也就是有一长串地址那个终端窗口会有对应的信息弹出。因为实战项目还有前端，后端要启动，不只是合约要启动，所以新建一个终端。这个网址一段时间不打开，要刷新一下，不然时间戳有可能是错的。启动hardhat，要在hardhat对应的文件夹下启动。接着，再新增一个终端，在新的终端输入。就可以跳转到对应的文件夹目录下。

山寨币，典型的是莱特币，因为莱特币发行的时间比较早，所以被大家认可软分叉：分叉是临时性的，很快就会更新，所以还是同一条链上硬分叉：是永久性的硬分叉：需要看是否有人认同，如果分叉出来的两条链都有人认同，那就两条链都有效，若分叉出来的两条链其中一条没有人认同，那那一条链之后就会废弃掉从原来区块链的项目中，分叉出来的叫做分叉链。典型代表就是比特币现金。若在2011年前购买了比特币，在这之后我就会凭空多一个比特币现金.

控制台报错：端口号被占用。若没有东西再弹出，则没问题。回到vscode控制台。

yarn -v (这个查看版本号可以等配置完环境再看)大家可以看下是否有安装镜像，我是之前就安装了淘宝镜像的。我不太记得我是否需要搞下面这个了，要是下次需要的话，记得。然后，再增加NODE_PATH这一行。原先有一个什么什么DApp的，改为。接下来，管理员身份打开vscode。给大家看下我的Node文件夹位置。这里的相对地址就是c2n-fe。先找到对应的前端代码文件夹。然后查看yarn版本号。cmd管理员打开，输入。cd ./相对地址/

2.在vscode打开一个新的文件，在终端输入 npx hardhat。1.将nodeJs的版本升级至18以上。

比特币是没有强一致性的，因为即便现在有一个一百的区块，另一条是八十的区块，如果算力够的话，80的区块也可以在短时间内追赶上一百的区块，那这样，80的区块就被公认为合法的区块了。若到期还款时，账户余额有钱，就自动划给对方，若账户余额没钱，则将抵押的东西自动划给对方。会随机将一位将军（记账者）的记账告诉其他的记账者，只要有三分之二以上的记账者是诚实的，就会达成强一致性。众筹：在商品未发出来的时候，就先购买它的代币。分叉：不同的人认可不同的账本，就会导致分叉。DAO：原有的，飘渺的规章制度写在程序上。

因为矿工得到的奖励只在这一条链上有效，若这一条链没有人认可，那这一条链上得到的奖励也是无效的。比如交易3指的是：因为账户上记录的都是分散的交易过程，他没有完整的32个比特币，因此，他需要多笔输出到别人的账户上。这种交易方式与传统的交易方式的不同的点在于：账户上不是以余额的方式记录下来，而是以交易过程记录下来。比如交易1指的是：a给了b20个比特币，a也给了自己30个比特币。区块链是比特币的底层支持，区块链解决了最根本的问题：信任问题。UTXO，未花费的交易输出：指的实质上就是账户上的余额。

解决方法缺少红色这一行。

然后根据这个地址 C:\WINDOWS\system32\npm，删除npm文件。问题 ：VSCode输入npm xxx，跳转到选择应用。解决方法：在终端输入。

如果按照单位时间获取的代币这样的计算方式，会有技术难点：因为每时每刻都有用户在进行提取或者存入操作，每进行一次提取或者存入操作都会影响分配的比例；某用户的存入或者是提取操作，会影响这个用户的reward更新操作。平台方会设立不同的池子，每个池子的比重，也就是含金量不一样。（rewardA的初始值就是A一开始存入的值，也就是0）add pool（）：设置总奖励，每秒奖励，分配点。用户的存入或者是提取操作，都会影响acc的更新操作。acc计算：历史的+这段时间，每个代币产生的收益。withdraw（）：提取。