以太坊：事件、日誌和布隆過濾器

布隆過濾器區塊鏈開發 · 發表 2018-12-15 00:00:00

引用網址： ofollow,noindex">https://www.cnblogs.com/zhizaixingzou/p/10122288.html

1. 事件、日誌和布隆過濾器

本文Java原始碼截圖來自開源的以太坊Java版本實現： https://github.com/ethereum/ethereumj

1.1. Solidity 中的事件在 Java 中被記錄為日誌

1.1.1. 包含事件定義和生成的 Solidity 原始碼

包含事件定義和生成的 Solidity 原始碼：

pragma solidity ^0.4.12;

contract EventDemo {
event Sent(uint indexed value, address from, uint amount);

constructor () public {
emit Sent(25, msg.sender, 56);
}
}

事件的引數可用 indexed 標記，標記後就可以生成布隆過濾器，以便合約的事件查詢。最多可以有 3 個 indexed 標記的引數，且 indexed 標記的引數必須在最前頭。

另外，因為主題都是一個個的 32 位元組儲存的，因而能作為 indexed 的不能是動態型別。

編譯後得到位元組碼：

6080604052348015600f57600080fd5b50604080513381526038602082015281516019927f2e0c9b7721d4bcc1b5781e2248e010b07b94a614f855a3406b43d03aad9ad4d2928290030190a260358060586000396000f3006080604052600080fd00a165627a7a72305820a916c71db2597b4b3d7c2a8311ac8bc79e96edb3187542cd0d464813a12dd2600029

對應的彙編程式碼：

PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH1 0xF JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH1 0x40 DUP1 MLOAD CALLER DUP2 MSTORE PUSH1 0x38 PUSH1 0x20 DUP3 ADD MSTORE DUP2 MLOAD PUSH1 0x19 SWAP3 PUSH32 0x2E0C9B7721D4BCC1B5781E2248E010B07B94A614F855A3406B43D03AAD9AD4D2 SWAP3 DUP3 SWAP1 SUB ADD SWAP1 LOG2 PUSH1 0x35 DUP1 PUSH1 0x58 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN STOP PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x0 DUP1 REVERT STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 0xa9 AND 0xc7 SAR 0xb2 MSIZE PUSH28 0x4B3D7C2A8311AC8BC79E96EDB3187542CD0D464813A12DD260002900

應用二進位制介面的 JSON 表示，包含了構造方法和事件的定義：

[
{
"inputs": [],
"payable": false,
"stateMutability": "nonpayable",
"type": "constructor"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"name": "value",
"type": "uint256"
},
{
"indexed": false,
"name": "from",
"type": "address"
},
{
"indexed": false,
"name": "amount",
"type": "uint256"
}
],
"name": "Sent",
"type": "event"
}
]

1.1.2. 執行合約得到日誌

在以太坊上執行上面的合約位元組碼：

日誌資訊通過 LogInfo 類記錄：

LogInfo{address=00a615668486da40f31fd050854fb137b317e056, topics=[2e0c9b7721d4bcc1b5781e2248e010b07b94a614f855a3406b43d03aad9ad4d2 0000000000000000000000000000000000000000000000000000000000000019 ], data=00000000000000000000000005792f204d45f061a5b68847534b428a127ae5830000000000000000000000000000000000000000000000000000000000000038}

address 記錄事件生成所在的合約地址。

topics 記錄主題列表，第一個是事件簽名的 SHA 3 編碼，編譯時就定了，使用了計算公式 keccak256("Sent(unit,address,uint)") 。接下來的主題，則分別對應了 indexed 的引數值，如這裡的 value 的 2 5 。

data 記錄沒有 indexed 標記的引數值，如這裡的 from 和 amount 的值。

LOGn ，其中 n 為 0~4 ，表示的是主題數量，如上面使用了 LOG2 ，表示有兩個主題，一個是事件簽名的 SHA3 編碼，一個是 indexed 修飾的引數。

1.1.3. 日誌資訊的解析

1.1.3.1. 通過 ABI 解析

可以看到，日誌資訊存放的資料並非直接可讀的，所以需要解析，方法如下：

注意，這裡的 JSON 按解析的要求使用的是陣列形式，只是我們只傳遞了一個事件的 ABI 。

得到的結果如下，即 args 為事件引數值：

記下來分析下解析過程。

1 ）通過 ABI 的 JSON 表示得到對應的 Function[ ] 例項。

這個 Function[] 實現是 Contract 的一個欄位。

2 ）根據日誌資訊的第一個主題得到對應的事件的 Function 。

可以看到，其過程是拿出合約的 Function[] 中的每一個，計算出簽名的 SHA3 值與日誌資訊的第一個主題比較，如果相等就篩除了此 Function 。

從這裡也可以看出事件簽名 SHA3 在 Java 上是如何等價實現的，即用到了事件名和引數型別來獲取簽名，沒有用到事件的其他組成。

3 ）根據事件的 Function ，解析主題列表和日誌資訊的 data 部分。

對應主題的解析，則直接使用 SolidityType 解析其型別值，如例子中的 value ：

org.ethereum.solidity.SolidityType.IntType#decode

對於未 indexed 的引數，則可能包含動態型別，解析過程如下：

可以看到 data 部分是每個非 indexed 引數各自 ABI 編碼後的簡單拼接，與合約呼叫時需要所有引數整體 ABI 編碼是不同的。

1.1.3.2. 通過事件簽名解析

 1 public static class Event extends Entry {
 2private static final Pattern EVENT_SIGNATURE = Pattern.compile("^(\\w+?)\\((.+?)\\)$");
 3private static final String PARAMETER_TYPE_SEPARATOR = ",";
 4private static final String INDEXED_SEPARATOR = " ";
 5 
 6/**
 7* Add parsing event form signature.
 8*
 9* @param signature event signature
10* @return Event instance
11*/
12public static Event fromSignature(String signature) {
13Matcher matcher = EVENT_SIGNATURE.matcher(signature);
14if (!matcher.find()) {
15throw new IllegalArgumentException("Event signature is illegal");
16}
17 
18String params = matcher.group(2).trim();
19if (StringUtils.isEmpty(params)) {
20throw new IllegalArgumentException("Event parameter list cannot be empty");
21}
22if (params.startsWith(PARAMETER_TYPE_SEPARATOR) || params.endsWith(PARAMETER_TYPE_SEPARATOR)) {
23throw new IllegalArgumentException(
24String.format("Event signature can not begin or end with %s", PARAMETER_TYPE_SEPARATOR));
25}
26 
27String eventName = matcher.group(1).trim();
28List<Param> eventInputs = new ArrayList<>();
29boolean indexedOver = false;
30for (String paramType : params.split(PARAMETER_TYPE_SEPARATOR)) {
31String[] paramPart = paramType.split(INDEXED_SEPARATOR);
32Param param = new Param();
33if (paramPart.length == 1) {
34param.type = SolidityType.getType(paramPart[0]);
35param.indexed = false;
36indexedOver = true;
37} else if (paramPart.length == 2 && !indexedOver) {
38param.type = SolidityType.getType(paramPart[0]);
39param.indexed = true;
40} else {
41throw new IllegalArgumentException(
42String.format("Event parameter \"%s\" is illegal", paramType));
43}
44eventInputs.add(param);
45}
46 
47return new Event(false, eventName, eventInputs, null);
48}

1.2. 布隆過濾器的應用

1.2.1. 布隆過濾器的簡介

在儲存一個數據時，我們將來可能要查詢它。為此，我們可以將此資料進行 N 個雜湊函式計算，得到 N 個值。假設這些數均勻分佈在 M 以內，那麼可以設定一個長度為 M 的位向量，根據得到的 N 個值，將位向量上對應的 N 個位置的為置為 1 。這就得到了一個布隆過濾器。對所有的資料都這樣，然後合併到這個布隆過濾器上。

要判斷一個數據是否儲存過，則也計算出這 N 個值，然後看布隆過濾器位向量相應位置是否都為 1 ，如果不是，則一定沒有儲存過，否則可能儲存過（之所以是可能，因為不同的資料可能覆蓋位向量的同一位）。如果全為 1 ，則再進行資料的具體比對。

可以看到，這可以大大加速資料的查詢，它可以快速排出未儲存的資料。

1.2.2. 為一個事件生成布隆過濾器

為一個事件，或者說一條日誌，生成布隆過濾器的過程如下：

org.ethereum.vm.LogInfo#getBloom

也就是說，將參與布隆過濾器生成的合約地址和各個主題，分別進行 SHA3 編碼，得到一個個 32 位元組的雜湊值。然後將根據這些雜湊值生成的布隆過濾器合併就得到了事件的布隆過濾器。

根據雜湊值生成布隆過濾器的過程是：

將布隆過濾器內部儲存的位向量設定為 2048 位，即 256 位元組。

取第 0 位元組的低 3 位和第 1 位元組組成 int 值 b ，它的最大值為 2 047 ，布隆過濾器位向量的第 b 位設定為 1 。

同理，取第 2 、 3 位元組，取 4 、 5 位元組，填充布隆過濾器位向量的指定位。

布隆過濾器的合併操作如下：

即將布隆過濾器的位向量同樣的位做或運算。

從上面的過程可知，一個事件因為最多 4 個主題，一個主題最多會設定 3 個位，所以一個事件在布隆過濾器中最多佔據位向量 2 048 位中的 12 位。

1.2.3. 為一個交易生成布隆過濾器

預設使用 256 位元組的位向量。

交易的布隆過濾器是所有的事件布隆過濾器的合併。

1.2.4. 為一個區塊生成布隆過濾器

區塊的布隆過濾器是所有的交易隆過濾器的合併，最後區塊的布隆過濾器存放在區塊頭。

1.2.5. 事件查詢

使用布隆過濾器可以大大加速事件的查詢。我們知道，以太坊會先建立各個主題的布隆過濾器，然後合併得到事件的布隆過濾器，再合併得到交易的布隆過濾器，最後合併得到區塊的布隆過濾器。而查詢滿足指定特徵的事件的過程則正好相反，即先根據查詢條件得到布隆過濾器，如果其位向量是區塊布隆過濾器的子向量，則認為可能在此區塊有，如果不是則就能判斷不是了，如果是有可能，則繼續對比區塊下各個交易的布隆過濾器，以此類推。最後如果匹配事件的布隆過濾器，則在進行嚴格的資料驗證，驗證相同則通過了。

這裡只展示了從交易的布隆過濾器開始查詢。

如果事件的某個欄位能夠作為查詢條件，那麼它應該定義為 indexed 。

下面看看以太坊的一個實現：布隆匹配的最終目標是日誌資訊，終極匹配為事件布隆過濾器的匹配。

1 ）布隆過濾器匹配。

org.ethereum.core.Bloom#matches

引數為傳進來的日誌特徵，如果它是本布隆過濾器的子布隆過濾器，則返回 true 。

2 ）提供給外部的查詢引數。

org.ethereum.listener.LogFilter

外界如何表達自己的查詢要求？

I、要查詢合約 A 內包含有主題 a 、 b 、 c 的事件，其布隆過濾器匹配過程要求的傳入是：

contractAddresses.length=1 。

contractAddresses[0]=A 。

topics.size=3 。

topic.get(0)=byte[][] ，其中 byte[][] 可以有多個值，表示任何一個值滿足，那麼該主題都是值滿足的，其他主題同理。

A 、 a 、 b 、 c 要同時存在且值滿足，則對應的日誌資訊是匹配的，就可以進入精確比對了，比對過則返回給查詢者。

II、如果要查詢的是多個合約含這些主題的事件，則 contractAddresses.length 相應變化且傳入值即可。

總之，對於是否匹配合約、指定主題則必須全滿足，而具體到某一個，則值中的任意一個匹配上就滿足了。