甲骨文如何证明交易是被挖掘的？

Question

我想构建一个类似于OmniBridge for xDai或任意消息桥的甲骨文，但我担心如何确保它的安全性。

这样的预言似乎应该是可靠的，只要有一种方法来获取一项交易的散列，并证明它包含在一个区块中，而该区块又是在“主要区块链”上开采的。(最后一部分是主观的，但只要我们能够在交易后证明足够的块难度，调用oracle的智能契约就可以得到满足)。我需要验证所有这些的组件是：

1. Merkle分支机构(或其他证据)表明该交易是在其区块内开采的
2. 验证有多少块是“合法地”挖掘的，直到我们找到“最新/顶级”块的散列( oracle只从块链节点获得)。
3. person将提供实际的事务参数，事务的散列必须由智能契约再次计算，以确保它是正确的哈希。

1，2，3甚至可能吗？这就是问题所在！

其想法是“兑现”X数量的FOO令牌，这些令牌被发送到上的智能合同并锁定在那里。例如，如果有人在xFOO链上发送相应的X个xDai令牌，并且该事务在几个块之后被“确认”，那么此人可以调用智能契约上的方法，并将X令牌释放到发送它们的钱包EOA地址。

安全性分析:据推测，在像xDai这样的足够大的区块链下，无论是PoW还是PoS，它都应该是安全的，但如果X足够大，可能有人想通过在上面挖掘更多假块来欺骗甲骨文网络，然后“证明”交易已经发生。不过，我想他们并不能真正愚弄甲骨文，因为关于ERC1677的xDai令牌合同会回滚任何没有足够余额的事务。为了伪造一个违反智能契约逻辑的事务，他们必须将整个xDai网络分叉，并造成很多混乱。

Answer 1

但是，我怎样才能验证中智能合同中的链上证据呢? 1,2,3似乎需要一些繁重的功能。

在智能契约内部，这是不可能的。在EVM中，每个块执行的契约调用有数百次，并且没有像您所请求的那样有空间处理复杂的逻辑。EVM提供的块链的唯一“连通性”是2种类型的对象：

1. 块上下文
2. 交易上下文

这些都是在core/vm/evm.go中定义的，下面是定义：

// BlockContext provides the EVM with auxiliary information. Once provided
// it shouldn't be modified.
type BlockContext struct {
    // CanTransfer returns whether the account contains
    // sufficient ether to transfer the value
    CanTransfer CanTransferFunc
    // Transfer transfers ether from one account to the other
    Transfer TransferFunc
    // GetHash returns the hash corresponding to n
    GetHash GetHashFunc

    // Block information
    Coinbase    common.Address // Provides information for COINBASE
    GasLimit    uint64         // Provides information for GASLIMIT
    BlockNumber *big.Int       // Provides information for NUMBER
    Time        *big.Int       // Provides information for TIME
    Difficulty  *big.Int       // Provides information for DIFFICULTY
}

// TxContext provides the EVM with information about a transaction.
// All fields can change between transactions.
type TxContext struct {
    // Message information
    Origin   common.Address // Provides information for ORIGIN
    GasPrice *big.Int       // Provides information for GASPRICE
}

https://github.com/ethereum/go-ethereum/blob/master/core/vm/evm.go

如您所见，您只能从事务上下文中获取发件人的地址(原产地)和GasPrice。对于区块，你可以得到矿工的地址，区块的号码，煤气的限制，时间和困难。就这样。

存储帐户信息的州trie (Merkle )不能以您想要的形式从合同中访问。事实上，Merkle的节点是由散列帐户构建的，因为团队担心安全性，并且希望确保合同无法确定地访问Trie的节点，因此帐户地址的散列使得您的帐户在trie中的位置完全是随机的。我的意思是，你是在要求一个Ethereum基金会明确禁止你拥有的功能。它公开了DDoS攻击的trie。(就我个人而言，我不认为这里有任何安全问题，但是，它是这样做的)

实现所需内容的唯一方法是在契约中定义相应的变量，并自己更新它们(如块散列、校对等)，其他人必须信任您的数据。

很久很久以前，我也在考虑如何自动连接两条链，但没有人的干预或权威的实体，我没有办法做到100%。问题是：

• 要在Ethereum主网上证明一些东西，您需要拥有完整的trie和创世纪块的所有块头。合同不可能做到这一点，它大约是500 GB的数据，它需要运行每一个块。
• 要证明Ethereum主网是从另一个链中修改的，您需要观察Ethereum主网的事件，这还需要有所有的块头和完整的状态trie。
• 因此，在两条链之间进行沟通的唯一方法是，如果你站在第三条线上，并且正在观察两条不同的区块链。

绝对证明在计算上是昂贵的，但信任是廉价的，这就是为什么每个人都使用受信任的实体并依赖某种类型的验证器。