BCSkill (Block chain skill )
区块链中文技术社区

只讨论区块链底层技术
遵守一切相关法律政策！

在 Arbitrum Nitro 中，交易预检查（TxPreChecker）是一种用于提前验证交易的机制，确保交易在实际执行之前满足一定的条件。TxPreCheckerStrictness 有四种类型，分别为：

1. TxPreCheckerStrictnessNone:

• 含义: 不进行任何预检查。这意味着交易在进入交易池或执行之前不会被验证。这种方式通常用于调试或不需要严格验证的场景。
• 适用场景: 适合于非常宽松的环境，例如测试或开发阶段。

2. TxPreCheckerStrictnessAlwaysCompatible:

• 含义: 仅检查交易是否与现有的交易和区块链状态兼容。它确保交易不会破坏区块链的一致性或引入不兼容的状态。
• 适用场景: 适用于需要最低限度的验证以确保基本兼容性，但不需要深入检查的场景。

3. TxPreCheckerStrictnessLikelyCompatible:

• 含义: 进行一系列基本的兼容性检查，确保交易很有可能与区块链状态兼容。这是一种折衷方案，比 AlwaysCompatible 更严格，但仍然不保证完全的安全性。
• 适用场景: 适用于在性能和安全性之间寻找平衡的场景，适合于较为宽松但仍需基本验证的环境。

4. TxPreCheckerStrictnessFullValidation:

• 含义: 对交易进行全面的验证，确保交易在所有方面都符合区块链的要求。这种严格的验证方式最大程度地减少了交易失败的可能性，并确保网络的安全性和一致性。
• 适用场景: 适用于对安全性要求非常高的场景，例如生产环境或关键交易。

这些严格性选项可以帮助开发者和操作人员在性能和安全性之间进行权衡，以满足不同的需求。

Arbitrum 和 Optimism 是两个最受欢迎的以太坊 Layer 2 扩展解决方案，它们都使用 Optimistic Rollup 技术来提高以太坊的可扩展性和降低交易成本。然而，这两个项目在设计、性能优化以及功能特性上有所不同。

1. 架构与设计

Arbitrum:

使用了一种更复杂的欺诈证明机制，称为多轮交互式欺诈证明。这种机制允许在链下进行高效的争议解决，并在链上进行最终判决。
具有更多的灵活性，允许链上验证在多个层次上进行，并支持更复杂的合约结构。

Optimism:

采用单轮欺诈证明机制，所有争议都必须在一个区块内解决，这种方法在某些情况下可能更简单，但也可能导致更高的链上负载。
更注重简单性，致力于尽量保持与以太坊主网的兼容性，尤其是 EVM 的兼容性。

2. 性能和延迟

Arbitrum:

由于其多轮欺诈证明机制，Arbitrum 在处理争议时可能更有效率，尤其是在处理复杂的合约争议时。这使得其网络在高负载下更具韧性。
Arbitrum Nitro 升级后，其交易成本大幅降低，吞吐量也显著提高。Nitro 的优化使得交易延迟更低，整体性能显著提升。

Optimism:

Optimism 的单轮欺诈证明机制可能在某些简单场景下具有更低的延迟，因为它避免了多轮交互。
但这种机制在处理复杂合约时可能不如 Arbitrum 高效，尤其是在争议处理过程中。
Optimism 在吞吐量和延迟方面表现良好，特别是在简单交易的处理上，通常更快。

3. 费用结构

Arbitrum:

由于优化了 Rollup 处理过程和欺诈证明机制，Arbitrum 在大多数情况下提供较低的交易费用。
Arbitrum Nitro 通过使用更高效的压缩算法和优化的 EVM 模拟器，进一步降低了费用。

Optimism:

Optimism 的费用结构略高于 Arbitrum，特别是在处理复杂合约时。
不过，对于普通用户，Optimism 仍然提供显著低于以太坊主网的费用。

4. 开发者生态与工具

Arbitrum:

提供了更多的开发者工具和支持，允许开发者构建更复杂的 dApp，并具有更灵活的部署选项。
更复杂的合约和 Rollup 机制意味着开发者可能需要适应 Arbitrum 特有的设计模式。

Optimism:

注重与以太坊的兼容性，尤其是 EVM 兼容性，使得开发者可以更容易地将现有的以太坊应用迁移到 Optimism。
提供了较为简单的开发体验，适合那些希望快速部署并兼容以太坊生态的开发者。

总结

• Arbitrum 在处理复杂合约和高负载时表现得更为出色，得益于其多轮欺诈证明和 Nitro 升级。其优化使得延迟更低，费用更低，并且提供更高的吞吐量。
• Optimism 则更侧重于简单性和与以太坊的兼容性，可能在处理简单交易时具有更快的速度和更低的延迟，但在复杂合约上可能不如 Arbitrum 高效。

最终的选择取决于你的应用需求。如果你的应用需要处理复杂的合约并且对性能有较高要求，Arbitrum 可能更合适。如果你更注重开发的简单性和与以太坊的高度兼容性，Optimism 可能是更好的选择。

该库提供 Github、Google、Facebook、Microsoft、Twitter、Yandex、Battle.net、Apple、Patreon 和 Telegram 的“社交登录”，以及自定义身份验证提供商和电子邮件验证。

• 可以同时使用多个 oauth2 提供程序
• 特殊dev供应商允许本地测试和开发
• JWT 存储在具有 XSRF 保护的安全 cookie 中。Cookie 可以是仅限会话的
• 最小范围仅包含用户名、ID 和图片（头像）
• 使用用户提供的凭证检查器直接进行身份验证
• 使用用户提供的发件人（电子邮件、即时通讯等）验证身份验证
• 自定义 oauth2 服务器并能够使用任何第三方提供商
• 集成头像代理与 FS、boltdb 和 gridfs 存储
• 支持用户自定义头像存储
• 默认头像的 Identicon
• 带有用户定义验证器的黑名单
• 支持多个受众
• 可定制的安全密钥SecretReader
• 能够将额外信息存储到令牌中并在登录时检索
• 预授权和后身份验证挂钩来处理自定义用例。
• 可轻松集成到 http 路由器的中间件
• 从请求中提取用户信息的包装器
• 基于角色的访问控制

https://github.com/go-pkgz/auth

import tweepy

# 你的Twitter API Key
consumer_key = 'your_consumer_key'
consumer_secret = 'your_consumer_secret'
access_token = 'your_access_token'
access_token_secret = 'your_access_token_secret'

# 设置API访问
auth = tweepy.OAuthHandler(consumer_key, consumer_secret)
auth.set_access_token(access_token, access_token_secret)
api = tweepy.API(auth)

# 检查用户是否转发了推文
def check_retweet(username, tweet_id):
    try:
        # 获取用户的转发列表
        retweets = api.retweets(tweet_id)
        for retweet in retweets:
            if retweet.user.screen_name == username:
                return True
        return False
    except tweepy.TweepError as e:
        print(f"Error: {e}")
        return False

# 使用示例
username = 'example_user'
tweet_id = '1234567890123456789'  # 你的推文ID
is_retweeted = check_retweet(username, tweet_id)
print(f"{username} has {'retweeted' if is_retweeted else 'not retweeted'} the tweet.")

https://developer.x.com/en/docs/twitter-api/tweets/retweets/introduction
https://developer.twitter.com/apitools/api?endpoint=%2F2%2Fusers%2F%7Bid%7D%2Fretweets&method=post

github: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/659f3063f82422cef820de746444e6f6cba6ca7c/contracts/utils/cryptography/SignatureChecker.sol

/**
     * @dev Checks if a signature is valid for a given signer and data hash. If the signer is a smart contract, the
     * signature is validated against that smart contract using ERC-1271, otherwise it's validated using `ECDSA.recover`.
     *
     * NOTE: Unlike ECDSA signatures, contract signatures are revocable, and the outcome of this function can thus
     * change through time. It could return true at block N and false at block N+1 (or the opposite).
     */
    function isValidSignatureNow(address signer, bytes32 hash, bytes memory signature) internal view returns (bool) {
        if (signer.code.length == 0) {
            (address recovered, ECDSA.RecoverError err, ) = ECDSA.tryRecover(hash, signature);
            return err == ECDSA.RecoverError.NoError && recovered == signer;
        } else {
            return isValidERC1271SignatureNow(signer, hash, signature);
        }
    }

测试例子

// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.19;

import {SignatureChecker} from "@openzeppelin/contracts/utils/cryptography/SignatureChecker.sol";

contract TestSignatureChecker {
    function verify(address _signer, bytes32 messageHash,  bytes memory _signature) external view returns(bool) {
        return SignatureChecker.isValidSignatureNow(_signer, messageHash, _signature);
    }
}