Indítsanak el most egy közvetlen blokklánc-pilóta projektet: kössenek össze egy valenciai élelmiszerexportőrt Rotterdam kikötőjének termináljával 30 napon belül, tokenizáljanak egy 40 lábas konténer és annak fuvarokmánya, valamint küldjenek élő eseményeket a vámhatóságok és a fuvarozó API-jai felé. Ez azonnali bizonyítékot ad minden fél számára a birtokviszonyról, időbélyegekkel és fizetési triggerekkel; a sikert egyetlen olyan konténerrel mérjék, amely nulla papír alapú korrekcióval kerül át, és rögzített birtoklási lánccal rendelkezik.
Kövesenek három konkrét lépést: 1) alkalmazzanak egy kompakt metadatémát a rakományattribútumok (romlandó, veszélyességi osztály, raklapok száma) osztályozására, és csatlakoztassanak szenzorazonosítókat; 2) telepítsenek él-intelligenciát (edge intelligence) a hőmérséklet és ajtónyitások figyelésére, és riasztásokat küldjenek, ha a határértékek túllépődnek; 3) képezzenek le eseményeket a kikötői EDI és a termináli operációs rendszer felé könnyűsúlyú webhookok használatával. Célzott mérőszámok: csökkentsék a kézi dokumentumkezelést 40–60%-kal, a vitarendezést 48 óra alá, és a termináli várakozási időt akár 36 órával csökkentsék annak a konténernek a esetében.
Allokáljanak feladatokat és erőforrásokat a skálázáshoz: rendeljenek ki egy mérnöki csapatot okosszerződés-sablonok felépítésére, jogi osztályt az tokenizált fuvarokmányok jóváhagyására, és üzemeltetést a kezelők és a vámhatóságok képzésére. Sikeres egyszemélyes futás után skálázzanak 10–50 konténer/hónap növekvő tételéhez, sokszorosítsák a modellt a valenciai exportőrök között, és kövessék nyomon az értéket konténerenként az alacsonyabb követelések, a gyorsabb kiadás és a csökkentett forgótőke összegeként. Priorizálják az API szabványosítást, a megfelelőséghez szükséges audit naplókat, és egy havi felülvizsgálati ütemtervet a tanulságok levonására és az értékek beállítására.
A kikötők és a hajózási társaságok számára, amelyek szélesebb körű elfogadást keresnek, azonnal alkalmazzák ezeket a KPI-okat: a tokenizált dokumentumokkal rendelkező szállítmányok százaléka, az átlagos ügyintézési idő órában, és a blokkláncon belüli intelligencia által jelzett kivételek száma. Használják ezeket az adatpontokat az útvonaltervezési szabályok finomítására, a konténerallokációk optimalizálására, és az érzékelőkbe és mérnöki kapacitásba történő növekményes befektetések igazolására, amelyek mérhető megtérülést jelentenek az érték és a megbízhatóság terén.
Első Blockchain Konténer Rotterdamba – Szállítási Mérföldkő és Kikötővárosi Kormányzás, Tervezés és Kikötő-Város Interakciós Esettanulmányok (Livorno & Valencia)
Valósítsanak meg egy közös pilóta projektet egy elosztott főkönyv üzembe helyezésével a konténeres események rögzítésére, a vámigazolások továbbítására és a kapukiadás automatizálására az első blokklánc konténer Rotterdam felé, majd skálázzák a validált modulokat Livornóba és Valenciába.
- Műszaki és kormányzati keretek: hozzanak létre egy közös irányító csoportot kikötői hatóságokból, önkormányzati tervezőkből, terminálüzemeltetőkből és üzleti szereplőkből a kikötői logisztikai célok és a városi tervezés összehangolása érdekében; a csoport heti műszaki felülvizsgálatot és negyedéves összehasonlító jelentést biztosít.
- Műszaki alap: rendeljenek ki mérnöki csapatokat a konténerkövetési felszólítások, az engedélyezett blokkláncon továbbított időbélyegzett dokumentumok, és a manifesztumok redundáns tárolásának integrálására; beleértve az API-kat, hogy a terminálok és a fuvarozók adatokat küldhessenek a meglévő TOS-okon (termináli operációs rendszerek) keresztül.
- Jogi és kereskedelmi háttér: készítsenek okosszerződéseket, amelyek tükrözik a meglévő kereskedelmi szerződéseket és a vámrendeleteket; használjanak professzionális jogi felülvizsgálatot a végrehajthatóság biztosítása érdekében, és hozzanak létre egy standard záradékokból álló portfóliót, amely meggyorsítja a szállítói bevezetést.
- Finanszírozás és beszerzés: célozzanak meg egy EU-s vagy nemzeti alapból a pilóta CAPEX finanszírozását; strukturálják a költségvetési sorokat, amelyek fedezik a middleware-t, a csomópont-hosztolást, az önvezető jármű interfézeket és a személyzeti tanulási modulokat; tervezzenek egy kiegészítő alapot, amely tartalékot képez a bevezetési késedelmekre.
- Érintett felek bevonása: vezessenek két hetes workshopokat terminálok, vámhivatalok, városfejlesztés és helyi vállalkozások képviselői számára, hogy működési korlátaik befolyásolják a rendszer tervezését; szisztematikusan rögzítsék a visszajelzéseket, és táplálják azokat a sprint backlogokba.
Összehasonlító elemzés Livorno és Valencia között
- Működési mutatók: A Livorno pilóta projekt 18%-kal csökkentette az átlagos tehergépjármű-várakozási időt három hónapon belül azután, hogy a tanúsítványokat on-chain továbbították, míg Valencia 22%-os csökkenést regisztrált a kapuautomatika és a megosztott tárolási manifesztumok integrálása után.
- Kikötő-város interakció: Livorno tervezési hivatala a tarifaváltásokra összpontosított, és módosította a zónázást a vontatási útvonalak rövidítése érdekében, ami 12%-os csökkenést eredményezett a városi tehergépjármű-forgalomban; Valencia a kikötői ütemezést az önkormányzati forgalomirányítással kötötte össze, ami gördülékenyebbé teszi a kikötőbe tartó járművek csúcsórában történő indulását.
- Adatkezelés: Mindkét kikötő elosztott engedélyezési modellt használt, amely a kereskedelmi szerződéseket és az érzékeny manifesztumokat nyilvános csomópontokon kívül tartotta, miközben kriptográfiai bizonyítékokat biztosított az auditőrök számára; ez a megközelítés figyelembe vette az adatvédelmi igényeket és a szabályozási hozzáférést.
Konkrét ajánlások és KPI-ok
- Hoznak létre egy minimálisan működőképes hálózatot Rotterdamon belül 90 napon belül: négy validátor csomópont (kikötői hatóság, két terminál, egy Vámhatóság) és egy csak olvasható csomópont a városi tervezés számára; KPI: csökkentsék az átlagos kapuvárakozást ≥20%-kal a pilóta terminálokon.
- Integrálják az önvezető udvari átadást, ahol lehetséges: teszteljék a blokklánc kiadási események és az önvezető vontatók indítása közötti kapcsolatot, hogy további 10–15%-kal csökkentsék az udvari várakozási időt.
- Írják elő a géppel olvasható igazolásokat a prioritásos rakományokhoz: követeljék meg a digitálisan aláírt növény-egészségügyi és biztonsági dokumentumokat, hogy azok automatikusan továbbíthatók és validálhatók legyenek, csökkentve a kézi ellenőrzéseket mérhető százalékkal.
- Hozzájanak létre egy közös összehasonlító jelentést a 6. és 12. hónapban, amely tartalmazza a mérnöki tanulságokat, a költség-elszámolásokat, és egy kockázati jegyzéket; használják a jelentést a hosszú távú szerződések beszerzésének finomítására, és a részt vevő vállalkozások körének bővítésére.
Hogyan javítja ez a kikötővárosi kormányzást és tervezést
- A városfejlesztés majdnem valós idejű átfutási adatokat kap, amelyek időbeli mintázatokat biztosítanak a forgalomirányítás és a tárolási igények számára, segítve a tervezőket a csúcsforgalom figyelembe vételében, és csökkentve a teherforgalom és a helyi mobilitás közötti konfliktusokat.
- Az önkormányzati hatóságok megbízható időbélyegeket és igazolásokat kapnak a kikötői rendszerből, így a városi szolgáltatások összehangolhatják a hulladékkezelést, a vészhelyzeti hozzáférést és a zajcsökkentést a kikötői műveletek körül.
- A vállalkozások tisztább átfutási időket és kevesebb vitát kapnak, mert a szerződéses mérföldkövek és a nyugták rögzítettek és auditálhatók; ez hozzáférhetőbbé teszi a láncfinanszírozási lehetőségeket, és csökkenti a várakozó rakományokban lekötött forgótőkét.
Bevezetési ellenőrzőlista (első 12 hónap)
- Hónap 0–1: alakítsák meg a közös kormányzást, biztosítsák az alap finanszírozási elkötelezettséget, rendeljék ki a mérnök vezetőket.
- Hónap 2–4: építsék meg a csomópontokat, integrálják a TOS API-kat, határozzanak meg okosszerződés-sablonokat, kezdjék el a személyzeti tanulási üléseket.
- Hónap 5–8: futtassák a pilóta projektet egy hajózási társasággal és két terminállal, mérjék a várakozási időt, a tárolási forgalmat, és a továbbított dokumentumok pontosságát.
- Hónap 9–12: tegyék közzé a összehasonlító jelentést, fejezzék be a szerződéssablonokat, bővítsék a csomópont-hálózatot harmadik fél logisztikai cégekkel és kiválasztott önkormányzati szolgáltatásokkal.
Végső megjegyzés: használják a pilóta adatok szisztematikus elemzését a beszerzés és a kikötői-logisztikai szabályok finomítására, hogy azok működési változásai skálázódjanak a kikötőkben; a Livorno-ból és Valenciából származó folyamatos tanulás révén a rotterdami modell megismételhetővé válik más tengeri csomópontok számára is.
Működési eljárások az első blokklánc konténer Rotterdamon belüli fogadása után
Standardizált elszámolási protokollt vezessenek be a hajó érkezése után 48 órán belül: jelöljenek ki egyetlen manifesztum tulajdonost, követeljék meg az e-aláírási engedélyt a fuvarozótól és a címzettől, valamint küldjenek valós idejű állapotfrissítést minden konténerhez; ez biztosítja a felelős átadásokat, és a pilóta negyedév végére célzottan 80%-kal csökkenti a kézi papírmunkát.
Az érkezés előtti teendők magukban foglalják az automatizált előzetes ellenőrzéseket, amelyek érvényesítik a fuvarokmányokat, az ISO kódokat és a veszélyes áru nyilatkozatokat a blokklánc manifesztummal szemben. Konfigurálják a kapukat úgy, hogy elfogadják a blokklánc tokeneket kiadási hitelesítőként, építsenek API adaptereket a hagyományos TOS/ERP rendszerekhez, és futtassanak párhuzamos kézi ellenőrzést az első 1000 mozgásra. Célrendszer elfogadási arányok: 95%-os pontos egyezés a dokumentummezőkben és 30 perces kapu áteresztőképesség a kiadott konténerek számára.
A működési átadás napi koordinációs hívásokat igényel különféle érintett felekkel: terminál üzemeltetők, vámhatóságok, szállítmányozók, belföldi fuvarozók és fuvarozó operatívrészlegek. Használjanak megosztott eseménynaplót, hogy a különböző csapatok láthassák az időbélyegzett eseményeket; követeljék meg, hogy minden résztvevő 2 órán belül jelentsen kivételeket. A világos szerepkör-meghatározások csökkentik az átfedést és tisztázzák, hogy ki vesz részt a vitarendezésben.
Az adatkezelési eljárásoknak mező-szintű eredetet, megőrzési szabályokat és audit mintavételt kell előírniuk. Mérjenek három KPI-t szállítmányonként: érkezéstől a digitális kiadásig eltelt idő, a megváltoztathatatlan bizonyítékkal rendelkező rekordok százaléka, és a kézi beavatkozás aránya. Tűzzenek ki célokat 48 órára, 99,9%-os bizonyíték jelenlétre és a kézi adatbevitel 60%-os csökkenésére az első évben. A pontos időbélyegek és az automatizált egyeztetés mérhető gazdasági előnyöket biztosítanak a terminálok és a szállítmányozók számára.
A kockázatkezelési kontrollok előre meghatározott tartalékokat tartalmaznak: aláírt PDF tartalék, zárolt token kiadás vitatott követelések esetén, és egyhetes peres eljárási felfüggesztés vitatott rakományok esetén. Határozzanak meg SLA büntetéseket és választottbírósági utat; korlátozzák a blokkláncon belüli bejegyzéseket a dokumentumok kivonataira az adatvédelmi szabályok tiszteletben tartása és a megváltoztathatatlan bizonyítékok megőrzése mellett. Képezzék a jogi és megfelelőségi csapatokat ezekben a hibrid koncepciókban a teljes bevezetés előtt.
A képzés és a változáskezelés ötvözze a tantermi foglalkozásokat gyakorlati szimulációkkal a gyakori eseményekről: vám elutasítások, papírmunka eltérések és kapu elutasítások. Futassanak három szakaszos pilóta projektet (50, 250, 1000 mozgás) egy 6 hónapos időszakon keresztül, visszajelzési ciklusokat gyűjtve, amelyek finomítják az okosszerződés szabályokat. A kikötői hatóságok és a fuvarozók világos víziója és folyamatos elkötelezettsége lehetővé teszi a szélesebb körű elfogadást, és skálázható automatizálást ígér.
Vegyenek át fokozatos technikai fejlesztéseket: integrálják az OCR és EDI feldolgozást, adjanak hozzá szerepalapú hozzáférést, és telepítsenek felügyeleti irányítópultokat, amelyek kiemelik a kivételeket. Folytassák a megbeszéléseket az interopébilis szabványokról, amelyeket már megtárgyaltak az EU szabályozókkal és technológiai partnerekkel; tartsák a blokkláncot az egységes igazság forrásaként, miközben más rendszereket szinkronban tartanak. Ez a gyakorlati, innovatív ütemterv biztosítja, hogy a rendszerek készen állnak a skálázásra, és hogy a működési koncepciók megismételhető eljárásokká válnak.
Hogyan validálják a termináli dolgozók a blokklánc alapú fuvarokmányokat a kapuban
Ellenőrizzék a fuvarokmány blokkláncon található kivonatát és a kibocsátó digitális aláírását a kapuban, mielőtt kiadják a konténert: követeljék meg az egyezést a bemutatott PDF/QR és a főkönyvi bejegyzés között, majd csak pozitív egyezés esetén folytassák a fizikai átadást.
Futtassanak automatizált lekérdezést, amely lekéri a tranzakció rekordot, és összehasonlítja a termináli adatbázisokkal; rögzítsék az ellenőrzés eredményét, az időbélyeget, a személyzeti azonosítót és az esetleges tevékenységjegyzékeket. A megváltoztathatatlanságot használják alap tesztként – ha a számított kivonat eltér a főkönyvi kivonattól, blokkolják a kiadást és azonnal escalated.
Kövesék nyomon a metrikákat naponta: átlagos kapu ellenőrzési idő, eltérés aránya, felülbírálatok 10.000 mozgásonként. Használják ezeket a KPI-okat a szűk keresztmetszetek és a továbbképzést igénylő csoportok azonosítására. Ez az adatvezérelt megközelítés támogatja az eljárások alakítását, amelyek skálázódnak a terminálokon keresztül, és ellenállóvá teszi a rendszert a későbbi csalásokkal szemben.
A blokklánc rekordok integrálása a Termináli Operációs Rendszerekkel (TOS): lépésről lépésre történő leképezés
Használjanak engedélyezett blokkláncot aláíró és rögzítő rétegként, miközben a TOS megtartja a kanonikus adatcsomagokat; állítsák be a blokk időt 3–5 másodpercre, a maximális köteget 150–200 tranzakcióra, és csak SHA-256 kivonatokat + minimális metadatot tároljanak a blokkláncon az immutabilitás megőrzése és a TOS feldolgozási késleltetésének 5 másodperc alatti tartása érdekében.
1. lépés – készletmezők és igazságforrások: soroljanak fel minden TOS mezőt, amelyet figyelembe kell venni a leképezésben (konténer_szám: 11 karakter, iso_típus_kód: 4 karakter, bruttó_súly_kg: egész szám ≤100000, hőmérséklet_c: lebegőpontos 1 tizedesjeggyel, veszélyes_áru_imdg: sztring, foglalási_ref: 35 karakter, fuvarokmány_szám: 34 karakter, pecsét_szám: 20 karakter, tulajdonos_fiók_azonosító: UUID, szállító_azonosító: UUID, terminál_esemény_kód: ENUM, időbélyeg_utc: ISO-8601, hely_szélességi/hosszúsági: tizedes 6 helyes). Mindegyiket egyetlen kanonikus névhez és adattípushoz rendeljék; beleértve a hivatkozást az UN/CEFACT alapvető elemekre, ahol lehetséges, hogy a kikötőkben és a tengeri mezőkben lévő különböző rendszerek azonos definíciókat használjanak.
2. lépés – kanonikus séma és üzenetformátumok: tegyenek közzé egy JSON Sémát (.json) és egy OpenAPI szerződést (.yaml) az összes eseménytípushoz (kapu_be, kapu_ki, kikötői_érkezés, rakodás_befejezve, kiszerelés_befejezve). Adjanak meg példákat: kapu_be adatcsomag mérete ≈1,2KB, köteg adatcsomag 100 eseményhez ≈120KB. A rögzített hosszúságú konténer_szám és az ISO időbélyegek érvényesítése a TOS beolvasás és a blokklánc rögzítés során elkerüli a feldolgozási hibákat.
3. lépés – adatvédelem, off-chain tárolás és immutabilitás: a nagy dokumentumokat (BL-ok, tanúsítványok) titkosított objektumtárolóban (AES-256) vagy IPFS-ben tárolják, blokkláncon lévő mutatóval és SHA-256 kivonattal; használjanak engedélyezett csatornákat vagy privát gyűjteményeket, hogy csak az arra jogosultak férhessenek hozzá a szöveges tartalomhoz. Ez a megközelítés auditálhatóságot biztosít az immutabilitásból anélkül, hogy blokklánc túlzsúfoltságot okozna.
4. lépés – integrációs minták és feldolgozási topológia: használjanak eseményvezérelt integrációt Kafka vagy RabbitMQ segítségével a TOS és a blokklánc middleware között; a TOS kanonikus eseményeket tesz közzé, a middleware érvényesíti a sémát, az adatcsomagot biztonságos tárolóba írja, a mutatót+kivonatot a blokkláncra írja, és egy megerősítő webhookot küld vissza a TOS-nak. Követeljenek meg idempotens üzenetazonosítókat és szekvenciaszámokat, hogy a rendszerek támaszkodhassanak az újrapróbálkozásokra, és túljussanak az átmeneti hálózati particionálásokon.
5. lépés – tranzakciós méretezés és SLA beállítás: állítsák be a blokk méretét és a commit intervallumot a csúcs terminál áteresztőképességének megfelelőre. Tipikus közepes termináloknál várhatók 100–300 kapu esemény percenként; állítsák be a blokk köteget 150-re és a commit intervallumot 3 másodpercre a kiszámítható késleltetés érdekében. Hosszabb feldolgozási feladatok (rakománytervezés, kiterjesztett egyeztetés) esetén használhatnak off-chain feladatokat fix intervallumú on-chain bizonyítvány-pillanatképekkel, hogy a teljes munkafolyamat auditálható maradjon valós idejű műveletek blokkolása nélkül.
6. lépés – egyeztetés, felügyelet és megbízhatóság: vezessenek be automatizált Merkle igazolás ellenőrzéseket és egy egyeztetési irányítópultot, amely 5 percenként összehasonlítja a TOS állapotát az on-chain rekordokkal. Kövessék nyomon ezeket a KPI-okat a pilóta során: sikertelen egyezés aránya, egyeztetési idő, és átlagos javítási idő. A pilóta eredményeit bemutató kutatók javasolják minden lépés instrumentálását, hogy egyetlen hiányzó mező vagy rossz formátum azonosítható legyen a pontos rendszerrel és időbélyeggel.
7. lépés – működési ajánlások kikötők és tengerészeti üzemeltetők számára: futtassanak egy három hónapos pilóta projektet célzott helyeken (kapu, udvar, hajó műveletek) a termelési forgalom integrációs veremre tükrözésével; határozzanak meg világos elfogadási kritériumokat (egyeztetés 60 percen belül, hibaarány <0,5%). Használjanak szerepalapú hozzáférést azonosító fiókokhoz és hardver biztonsági modulokhoz az aláíráshoz. Figyeljék a teherautó fordulási idők csökkenését és az útvonaloptimalizálást a mozgások optimalizálásából és az üres járatok csökkentéséből eredő szennyezés előnyeinek számszerűsítésére.
8. lépés – skálázás, hosszú távú karbantartás és jövőbiztosítás: tegyenek közzé egy verziósult szerződést és migrációs eljárást a séma változásokhoz (kisebb változások additív mezőkkel; törő változások visszamenőlegesen kompatibilis adapterréteggel). Ütemezzenek negyedéves felülvizsgálatot az kanonikus sémára és egy kiterjesztett kompatibilitási ablakot 6 hónapra a mezők elavulása előtt, hogy az utódrendszerek túljussanak a frissítéseken. Ezeknek a szabályoknak a bemutatása az integrációs specifikáció kormányzati részében egyetlen felhatalmazási forrást biztosít az egész ökoszisztéma számára az implementálók számára.
Vámi egyeztetési protokoll a blokklánc manifesztum és a nemzeti e-bevallások között
Valósítsanak meg egy determinisztikus, több szakaszos egyeztetési protokollt, amely a blokklánc manifesztum rekordokat a nemzeti e-bevallásokkal egyezteti kivonatolt mezőpárok, időablakos cserék és egy kivétel API segítségével a gyors feloldás érdekében.
A rekordokat fix kulcskészlettel egyeztessék: konténer azonosító, fuvarokmány szám, HS kód, adószáma a címzettjének, bruttó tömeg és pecsét száma. Követeljenek pontos egyezést a konténer azonosítón és BL-en, engedjenek ±2%-os numerikus toleranciát a tömegen, és fogadjanak el név egyezéseket Levenshtein távolsággal ≤2 a feladó/címzett esetében. Számítsanak ki mező-szintű Merkle gyökeret manifesztumonként, és foglalják bele ezt a gyökeret az e-bevallási beküldésbe, hogy a vámhatóság ellenőrizhesse az integritást teljes adatcsomag csere nélkül. Például, a pilóta adatok 78%-os csökkenést mutattak a manuális eltérésekben, amikor a kikötők Merkle gyökereket cseréltek ki teljes egyezési szabályokkal.
Csere gyakoriság: küldjenek aláírt manifesztum összefoglalókat 5 percenként a terminál csomópontokról; küldjenek teljes részletű szállítmányokat óránként vagy igény szerint kivételek esetén. Méretezzenek meg a üzenet adatcsomagot átlagosan 1,2 KB per sor; méret tesztekkel ellenőrizzék az 50 000 sor/nap (≈2100 sor/óra) áteresztőképességet egyetlen API átjárónál, 99%-os késleltetéssel <300 ms per API hívás. Utasítsák el az eltéréseket kódolt okokkal (séma, kivonat, mező-tolerancia), és engedjenek két automatikus újrapróbálkozást az emberi felülvizsgálatra való felterjesztés előtt.
Használjanak szerepalapú engedélyezési modellt: a vám csomópontok végeznek ellenőrzést és emelnek kivételeket, a fuvarozó csomópontok írják alá a manifesztumokat, a terminál üzemeltetők biztosítják a kapu időbélyegeket, a kikötői hatóságok pedig egy megosztott csak olvasható archívumot tárolnak. Rögzítsenek minden műveletet on-chain a transzparens auditálhatóság érdekében, és tároljanak anonimizált adatcsomagokat egy nemzeti e-bevallási adattárban az adatvédelmi megfelelőség érdekében. Vezessenek be automatizált vitarendezést: amikor kivétel merül fel, értesítsék a fuvarozót egy 30 perces SLA-val a korrekcióra; ha nem oldódik meg, terjeszszék fel a vámhatósághoz 4 órán belül, aláírt bizonyítékokkal csatolva.
Működési célok egy 3 hónapos pilóta programon keresztül, amelyben együttműködik a vámhatóság, egy tengeri terminál, egy fuvarozó és két helyi inkubátor; beleértve egy diákvezetésű fejlesztési szálat a felhasználói felület munkafolyamatainak és csere adaptereinek prototípusozásához. Mérjenek hetente KPI-okat: egyeztetési arány, manuális kivételek 1000 soronként, minimális ügyintézési idő, és sikeres aláírt cserék százaléka. A korai termelési mutatók egy közelmúltbeli pilóta projektből azt mutatták, hogy a manuális beavatkozások 68%-kal csökkentek, és az ügyintézési idők 35%-kal javultak a protokoll integrálása után.
Biztonság és kormányzás: követeljék meg a csomópont tanúsítást, az éves kulcsforgatást, és az on-chain kormányzási szavazásokat a séma változásokhoz 60 napos felülvizsgálati ablakkal. Tartsanak fenn egy moduláris adapter portfóliót az ASYCUDA, UN/EDIFACT és nemzeti API-khoz, hogy a program joghatóságokon át kiterjeszthető legyen. Javasolják a befektetést a személyzeti képzésbe, a folyamatos felügyeletbe és az inkubátor partnerségekbe a technológia skálázása, valamint a részes felek közötti jövőbeli ellenálló képesség és átlátható együttműködés biztosítása érdekében.