由於區塊鏈的分散特性，不同區塊鏈間的互操作性一直是一個具有挑戰性的課題。這就是為什麼「區塊鏈跨鏈橋」應運而生。讓我們一起深入探索區塊鏈跨鏈橋的概念、流程以及其所帶來的不可思議效益。 什麼是區塊鏈跨鏈橋？ 區塊鏈跨鏈橋是一種技術，它允許不同區塊鏈之間的相互連接和互操作。它建立了一條虛擬的橋樑，使得在不同區塊鏈間傳輸資產、數據和訊息成為可能。這樣一來，不同區塊鏈的用戶就能夠跨越這座橋，實現資產的無縫轉移和數據的即時共享。 區塊鏈跨鏈橋的流程 讓我們透過以下的例子，更深入地了解區塊鏈跨鏈橋的流程。 假設我們有兩個區塊鏈：A鏈和B鏈，它們具有不同的協議和運作方式。 一個用戶在A鏈上擁有一些資產，希望將其轉移到B鏈上。該用戶首先將資產鎖定在A鏈上，以確保安全性。 接下來，用戶需要將鎖定的資產的訊息發送到跨鏈橋合約。這個合約存在於A鏈和B鏈之間，負責協調跨鏈資產的轉移。 一旦合約收到訊息，它會驗證用戶的身份和鎖定的資產。這確保了資產的安全性和有效性。 合約在B鏈上解鎖相應的資產，並將其分配給用戶的帳戶。 整個流程完成後，用戶在B鏈上就能夠使用他們的資產了。這一切都在不同區塊鏈間實現了無縫的互操作。 區塊鏈跨鏈橋的出現為數位資產的流動性和價值轉移提供了新的可能性。這不僅促進了區塊鏈之間的互聯互通，還為用戶提供了更大的選擇和便利。透過區塊鏈跨鏈橋，用戶可以在不同區塊鏈間自由地轉移資產，進一步推動了區塊鏈技術的發展和應用。 Ethereum 的 USDC 與 Avalanche 的 USDC 差別 同樣是 Circle 發行，但並不是同一個東西，這邊想成是不同國家(鏈)的美元(這邊的美元都是每個國家自己發行掛鉤的)，所以也不能混用。 Ethereum 的 USDC 可以轉換到 Avalanche 鏈上嗎? 可以，透過 Avalanche 提供的跨鏈橋合約得到 USDC.e，使用跨鏈橋接協議，Ethereum USDC 資產鎖定。這個過程將生成相應 Avalanche 的USDC.e。反之需要看有沒有提供流動性。 具體流程如下: 你在 Ethereum 有 1000 USDC，你想在 Avalanche 鏈上靈活使用資產，因此需要轉換到 Avalanche 鏈上。 透過跨鏈橋對跨鏈合約，將 1000 USDC(ETH) 送入 跨鏈合約實確實收到後，自動生成 1000 USDC.e(Avalanche) 打入錢包 完成 Avalanche USDC vs Avalanche USDC.e 差別 Avalanche USDC 與 Avalanche USDC.e 都是 circle 所發行，Avalanche USDC 作為一個原生代幣他提供幾個優勢:...

概念 WBTC 與 WETH 概念都是相同的，最主要目的就是將代碼打包成 ERC-20 的代幣模式使其好操作以及和 DAPP 作交互。 原生加密貨幣 ETH 是無法與 DAPP 作交互，交互的東西只能是智能合約，先建立這個概念，那麼假如我們今天持有 10 ETH，想要玩一些項目，例如作雙幣理財(ETH/USDT)，簡單來說就是對池子提供流動性，而 DEX 或 CEX 會提供對應的利息給你。在 Ethereum 鏈上原生加密貨幣 ETH 無法進行交互，這時候會需要將 ETH 打包成 WETH (Wrapped Ether) 就是一份 ERC-20 的代幣來與 USDT (ERC-20) 與 DEX/CEX 作交互參與交易。 這張圖說明了原本 ETH 鏈上原生加密貨幣 ETH 無法與 ERC-20 作交互的情況。 這時候會發現那麼我使用 ETH 原生加密貨幣去購買例如柴犬幣跟換成 WETH 會有什麼差別？本質上操作邏輯是一樣的，但 WETH 合約的內容跟一般 ERC-20 代幣差別就是他與 ETH 是 1:1 掛鉤，不會有波動的問題，也就是這份合約能讓你隨時隨地將 ETH 和 WETH 作等價交換。 加密貨幣 與 代幣 的差異 加密貨幣(crypto currency): 鏈的原生貨幣，作為 gas fee 和 獎勵機制使用的貨幣。 代幣(token): 透過智能合約(smart contract) 所 mint 出來的代幣項目。 Chain crypto currency token Bitcoin BTC 不支持智能合約 Ethereum ETH USDT/DOGE/WETH/MATIC Avalanche AVAX USDT/USDT....

如果要提供給前端作即時表單驗證時，傳統作法是要在提供一組 API 作為驗證返回使用，Laravel Precognition 這個新的 Laravel 套件提供了較為方便的即時驗證，並且不會讓驗證規則同時存在兩份，也與前端框架作了整合，以下將以註冊功能添即時驗證為範例。 前置 配置 Breeze $ laravel new laravel10 $ cd laravel10 $ composer require laravel/breeze --dev $ php artisan breeze:install $ php artisan migrate $ npm install $ npm run dev 原本規則 預設配置好之後，原本的規則寫法是送表單型態，也就是說在送出表單當下才會去驗證欄位機制，這邊如果要調整成即時作表單驗證會有兩種作法： 前端取得後端驗證規則後以 JS 再寫入一次規則 後端提供驗證 API 操作 這邊可以看到前端寫規則的話當需要作欄位驗證調整時就得再調整，規則分散在兩邊; 而後端自行提供驗證 API 操作需要經過一定設計才會讓代碼不會有重複的狀況。 Laravel Precognition 在先前版本中提供了一種新的工具 Precognition 就是用來解決這個煩惱的。 routes/auth.php 添加中間件作為驗證機制 Route::post('register', [RegisteredUserController::class, 'store'])->middleware([HandlePrecognitiveRequests::class]); Http/Controllers/Auth/RegisteredUserController.php 將 Validation rule 複製 創建 RegisterRequest $ php artisan make:request RegisterRequest 刪除 authorize 或是改為 true 添加規則，用於判斷送入與即時驗證 precognitive 要驗證什麼，我這邊僅先用 unique 作範例 return [ 'name' => ['required', 'string', 'max:255'], 'email' => [ // 判斷成立 -> 展開陣列到上層陣列 ....

Laravel 功能相當強大且實用，本篇文章將逐步探索 Laravel 核心生命週期機制和註解理解的流程和功能，不難發現其實核心設計是相當巧妙且具有高彈性和客製化，從 public/index.php 進入點出發，理解其核心運作原理和概念會有助於後續客製化和開發，文末會簡單列出核心步驟方便大家在設計代碼時參考。 Entry point // public/index.php <?php use Illuminate\Contracts\Http\Kernel; use Illuminate\Http\Request; // 定義了常數 LARAVEL_START，其值為當前時間的微秒數，用於計算應用程式的啟動時間 define('LARAVEL_START', microtime(true)); // 檢查應用程式是否處於維護模式。 // 如果存在，則引入該檔案。維護模式用於暫時關閉應用程式，以進行維護或升級。 if (file_exists($maintenance = __DIR__.'/../storage/framework/maintenance.php')) { require $maintenance; } // 用於自動載入所需的依賴項和類別 require __DIR__.'/../vendor/autoload.php'; // 這邊會細說，這邊會返回 app instance $app = require_once __DIR__.'/../bootstrap/app.php'; // 使用 Service Container 解析實作 Http Kernel 接口的實例。 $kernel = $app->make(Kernel::class); // 使用 Request::capture() 捕獲了當前的請求，並將其傳遞給 handle() 方法進行處理。handle() 方法處理請求並返回一個回應對象，並將其賦值給 $response 變數。 $response = $kernel->handle( $request = Request::capture() )->send(); // 使用 terminate() 方法通知 Kernel 實例已經處理完畢，並傳遞了原始請求和回應對象。這個方法在應用程式執行結束後執行，例如在回應被送出到瀏覽器之後。 $kernel->terminate($request, $response); 核心 Application: Service Container 上面代碼是講述 Laravel 整個生命週期運行的步驟，接下來說明 app....

Optimistic Features: Uses fraud proofs to ensure the security of transactions. Is a rollup-based scaling solution, which means that it can achieve scalability by batching transactions and processing them off-chain. Is compatible with most Ethereum-based dApps. Has a large user base and a wide range of dApps deployed on it. Pros: Is fast and efficient. Has low transaction fees. Is easy to use. Has a large user base and a wide range of dApps deployed on it....

Container 機制是一種依賴注入的設計模式，它允許您將對象的創建和解析分離。這意味著您可以在應用程序中創建一個容器，然後使用容器來解析對象，而不是直接創建它們。這樣做的好處是，您可以更輕鬆地管理對象之間的依賴關係，並且可以更輕鬆地進行單元測試。 Container 機制通常由一個容器類別實現，該類別包含一個綁定數組，用於存儲抽象類別和具體類別之間的映射。當您需要解析一個對象時，容器會查找該對象的綁定，然後使用綁定中指定的具體類別或 Closure 創建該對象。 Container 機制還支持單例模式。如果您需要在應用程序中共享一個對象，則可以使用 singleton 方法來綁定抽象類別到具體類別或 Closure，並將 shared 參數設置為 true。這樣做可以確保每次解析該對象時都返回同一個實例。 使用 ReflectionClass 來解析對象，並使用 ReflectionParameter 來獲取對象的構造函數的參數列表。然後，它遞歸地解析每個參數的依賴關係，直到所有依賴關係都被解析為止。如果對象沒有構造函數，則直接返回一個新的對象實例。否則，它會使用 ReflectionClass::newInstanceArgs() 方法創建一個新的對象實例，並傳遞解析後的依賴關係作為參數。這種方法的好處是，它可以更輕鬆地管理對象之間的依賴關係，並且可以更輕鬆地進行單元測試。 基礎 Container 實作 <?php require_once 'Container.php'; class Foo {} $container = new Container; // 綁定 foo => new Foo $container->bind('foo', function ($container) { return new Foo; }); $foo1 = $container->make('foo'); var_dump($foo1); // object(Foo)#3 (0) { } 具體來說是怎麼實現這種綁定 Container，以下會逐步實現： 實現 bind class Container { protected $bindings = []; // 綁定一個實例進入 container public function bind($abstract, $concrete = null, $shared = false) { // $shared 參數用於指示是否應該返回同一個實例。 // 如果 shared 參數設置為 true，則返回同一個實例。 // 這對於需要共享的對象非常有用，例如資料庫連接或日誌記錄器。 // 如果 shared 參數設置為 false，則每次調用 make 方法時都會創建一個新的實例。 $this->bindings[$abstract] = compact('concrete', 'shared'); // array(1) { ["foo"]=> array(2) { ["concrete"]=> object(Closure)#1 (1) { ["parameter"]=> array(1) { ["$container"]=> string(10) "" } } ["shared"]=> bool(false) } } } ....