九層天塔DAPP系統開發技術|鏈上智慧合約dapp開發方案

分散式應用程式是資料的重要消費者，並需要節點將這些資料提供給在鏈上執行的使用者或應用程式。

我們可以使用Oracle網路以可信且高效的方式提供資料流，使加密網路能夠在可靠且分散化的方式下與傳統和區塊鏈系統進行互動。在這方面，Supraoracles、API3和Chainlink是一些示例。

改善應用程式的使用者介面和使用者體驗

在鏈上訊息傳遞仍然是區塊鏈基礎設施的關鍵組成部分。

隨著零售需求的增長，九層天塔DAPP系統13z開4z77發z558，應用程式/協議與其使用者以分散化且有意義的方式互動的能力將是增長的關鍵驅動因素。

在鏈上訊息傳遞可能有用的一些潛在領域包括：通知使用者領取回報/代幣、在錢包中內建通訊訊息以及通知/公告重要協議更新。在這方面，EPNS和XMTP是一些示例。

改善鏈上資料可用性

構建在區塊鏈上的應用程式依賴於鏈上和外部資料。

儲存在鏈上的資料未以可以有效或輕鬆地被Dapp使用的格式註冊。為了做到這一點，資料需要被索引和組織以進行高效檢索。

我們可以透過構建允許我們以分散化和強大的方式查詢和索引區塊鏈資料的協議來做到這一點。在這方面，The Graph、Covalent等是一些示例。

為多鏈世界做好準備

隨著整個區塊鏈生態系統的擴張和一層和二層生態系統(Rollups)的數量增加，跨鏈橋樑的管理和互操作性變得越來越重要。

跨鏈橋樑允許原本孤立的生態系統進行有意義的互動——這類似於新貿易路線幫助連線不同地區，引領著知識分享的新時代。

我們已經建立了廣義的資訊傳遞解決方案，例如Layer Zero、Axelar和其他跨鏈解決方案，支援廣義的資訊傳遞，允許所有型別的資料和資訊(包括代幣)在多個生態系統之間移動。使多鏈夢想成為現實。

從starknet跨鏈到ethereum主網是比較簡單的。

一個簡單的例子如下:

let mut message_payload:Array<felt252>=ArrayTrait::new();

message_payload.append(WITHDRAW_MESSAGE);

message_payload.append(l1_recipient.into());

message_payload.append(amount.low.into());

message_payload.append(amount.high.into());

send_message_to_l1_syscall(

to_address:read_initialized_l1_bridge(),payload:message_payload.span()

);

當我們在cairo合約中呼叫send_message_to_l1_syscall函式時，starknet節點會收到to_address和payload的資訊，其中to_address是L1資訊接收地址，而payload為傳送的資訊內容。節點收到上述資訊後，會使用以下公式計算hash值:

keccak256(

abi.encodePacked(

FromAddress,

ToAddress,

Payload.length,

Payload

)

);

其中各引數含義如下:

FromAddress L2傳送方地址

ToAddress L1接收方地址

Payload傳送資訊

計算完成後會將上述內容使用abi.encodePacked進行序列化，以其作為引數請求L1的核心合約中updateState函式，該函式有很多作用，此處我們僅關注L2->L1跨鏈資訊傳遞功能。此功能是透過processMessages函式實現的，其中核心部分如下:

if(isL2ToL1){

bytes32 messageHash=keccak256(

abi.encodePacked(programOutputSlice[offset:endOffset])

);

emit LogMessageToL1(

//from=

programOutputSlice[offset+MESSAGE_TO_L1_FROM_ADDRESS_OFFSET],

//to=

address(programOutputSlice[offset+MESSAGE_TO_L1_TO_ADDRESS_OFFSET]),

//payload=

(uint256[])(programOutputSlice[offset+MESSAGE_TO_L1_PREFIX_SIZE:endOffset])

);

messages[messageHash]+=1;

}

此處的programOutputSlice即節點打包的請求引數，我們使用陣列檢索來實現請求引數的反序列化。值得注意的是，這些請求引數並沒有被儲存在以太坊狀態中，而僅作為LogMessageToL1事件丟擲。該事件定義為:

event LogMessageToL1(uint256 indexed fromAddress,address indexed toAddress,uint256[]payload);

1

故在上述程式碼中，只有messages[messageHash]+=1;進行了以太坊狀態修改，所以歸根到底，只有L2->L1的資訊的雜湊值被記錄了。

原文連結：https://blog.csdn.net/WongSSH/article/details/130311981