---
title: "Pag-optimize ng Blockchain: Pangunahing mga Bottleneck"
description: "Bakit bumabagal ang mga blockchain: ang scalability trilemma, mga mempool, gas, gastos sa consensus, at ang mga engineering trade-off sa likod ng bawat “aayusin na lang natin mamaya.”"
language: tl
published: 2026-04-08
author: Netts
topic: "Insights"
canonical: https://netts.io/blog/optimization-of-blockchain-main-bottlenecks?lang=tl
languages: [en, ru, es, zh, th, fr, uk, tr, hi, fa, ar, ha, pt, vi, ko, ja, id, de, tl]
translation_outdated: false
---
# Pag-optimize ng Blockchain: Pangunahing mga Bottleneck

Bakit bumabagal ang mga blockchain: ang scalability trilemma, mga mempool, gas, gastos sa consensus, at ang mga engineering trade-off sa likod ng bawat “aayusin na lang natin mamaya.”

Maaaring magmukha sa karaniwang user na ang crypto blockchain ay isang seamless, perpektong makina na walang anumang depekto. Gayunpaman, nakakaranas lamang sila ng mga kapintasan kapag ginagamit mo na ang mga ito — tulad ng mga transaksyong naiipit o kapag bumabagsak ang mga server, o nagkaroon ng bug, atbp. Ano ang nasa likod ng lahat ng ito? Ang blockchain para sa mga hindi pa pamilyar ay isang mistikal na digital ledger, isang panandaliang nilalang na umiiral kahit saan at wala kahit saan, na agad-agarang nagpoproseso ng paglilipat ng halaga nang halos walang anumang error.

Ngunit ang totoo ay mas nakatuntong ito sa lupa. Kapag ang isang transaksyon ay naipit sa mempool nang ilang oras, dahilan upang mapalampas ng isang user ang mahalagang DeFi liquidation, o kapag ang network congestion sa panahon ng isang sikat na NFT mint ay nagbura sa lahat ng pag-asang makapagsagawa ng kumikitang trade dahil sa gas fees na lumampas pa sa kabuuang halaga ng transaksyon, hindi lamang iyon mga simpleng software bug. Ang mga ito ay side effect ng mga likas na bottleneck na kinakaharap ng bawat desentralisadong network.

Hindi lamang dahil hindi ito dulot ng tamad na programming o kawalan ng pagsisikap. Sa kabilang banda, ang ilan sa pinakamahuhusay na computer scientist at cryptographer sa buong mundo ay nagtatrabaho gabi't araw upang lutasin ang mga ito. Ngunit sumalpok sila sa matitigas na limitasyon ng pisika, kapasidad ng hardware, at ang mga di-maiiwasang trade-off ng mga distributed system. Upang malaman kung bakit naipit ang iyong transaksyon, o kung bakit mabagal ang network, kailangan nating silipin ang ilalim ng hood sa mga gear at lever na nagpapatakbo sa makinang ito — kabilang ang friction na nagpapabagal dito.

## Ang Scalability Trilemma at mga Limitasyon ng Throughput

Ang scalability trilemma marahil ang pinakakilalang bottleneck sa blockchain. Ayon sa teoryang triangle ng mga blockchain ni Vitalik, ang isang blockchain ay maaari lamang magkaroon ng 2 sa mga sumusunod: decentralization, security, at scalability. Hindi mo maaaring makuha ang lahat sa pinakamataas na antas. Hindi ito panuntunang naka-encode ayon sa algorithm, kundi isang natural na limitasyon sa kung paano gumagana ang mga distributed network. Kung nais mo ng network na napakabilis (scalable) at secure, kadalasang kailangan mong gumawa ng mga trade-off kung saan nababawasan ang decentralization sa pamamagitan ng pagkakaroon ng mas kaunting node na nagbe-verify ng mga transaksyon. Mayroon kang trade-off: kung nais mong maging parehong decentralized at secure ito, tulad ng Bitcoin o Ethereum, isusuko mo ang bilis. Ito ang dahilan kung bakit kaya lamang ng Bitcoin ang humigit-kumulang 7 transaksyon bawat segundo (TPS) at ang Ethereum ay gumagawa ng humigit-kumulang 15 — 30 TPS sa base layer, habang ang Visa ay kayang humawak ng sampu-sampung libo.

Dito, ang bottleneck ay ang block size at oras. Ang isang madali at malinaw na solusyon para mapataas ang throughput ay ang pagpapalaki ng block size upang magkasya ang mas maraming transaksyon, o bawasan ang block time upang mas mabilis tayong mag-mine ng mga block. Ngunit dito natin natatamaan ang pisikal na limitasyon: propagation delay. Kapag may natuklasang bagong block ang isang miner o validator, kailangang ipadala ang block na iyon sa bawat iba pang node sa network. Ang datos na ito ay naglalakbay sa mga kable ng internet, fiber optics, at mga router ng mundo. May mga limitasyon siyempre: bilis ng liwanag, bandwidth ng imprastraktura ng internet. Kung masyadong mabigat ang isang block, maaaring mas matagal itong i-download at i-verify. Ang labis na dami ng mga block na mabilis na napoprodyus nang sabay-sabay ng iba't ibang miner habang ang pangalawa sa pinakabago ay hindi pa naipapakalat ay maaaring magbunga ng "mga fork" o "orphan block" (o "mga uncle" sa Ethereum).

Ang mataas na uncle rate ay nagpapahiwatig na nagsasayang ang network ng computing power sa mga block na hindi napapasama sa main chain, na nagpapahina sa seguridad dahil nahahati ang tapat na hashing. Samakatuwid, ang limitasyon sa TPS ay, sa diwa, isang limitasyon sa synchronisation ng network. Bukod dito, ang bawat block ay may limitasyon sa “gas limit” o “block weight”. Ginagawa ito hindi lamang upang lagyan ng hangganan ang throughput kundi upang protektahan din laban sa mga Denial of Service (DoS) attack. Kung walang limitasyon kung gaano karaming kompyutasyon ang maaaring taglayin ng isang block, maaaring i-spam ng isang umaatake ang network ng mga masalimuot na transaksyon na aabutin nang napakatagal bago maproseso at magpapatigil sa buong sistema.

## Layer 2 at ang Scalability Bottleneck Dulot ng Data Availability

Upang maiwasan ang mga restriksyon ng Layer 1, nag-imbento ang industriya ng mga solusyon sa Layer 2 - partikular na ang "mga rollup". Ang mga protocol na ito ay nagsasagawa ng mga transaksyon off-chain, tinitipon ang mga ito sa isang block, at pagkatapos ay nagbabalik ng ilang compressed na bersyon o cryptographic proof sa main chain (Layer 1). Mukha itong perpektong ideya, gayunpaman nagdudulot ito ng karagdagang pasanin: DA (data availability). Kahit na ang kompyutasyon ay nagaganap off-chain, dapat naroroon on-chain ang sapat na impormasyon upang “muling buuin” ang estado ng rollup nang sa gayon ay masuri ito ng sinuman.

![](https://netts.io/blog/articles/optimization-of-blockchain-main-bottlenecks/images/1-1.png)

Ang block space sa main chain ay napakahalaga at limitado. Halimbawa, magiging magastos ang mag-post ng napakalaking dami ng call data sa Ethereum. Iyon din ang dahilan kung bakit nakikita natin ang mga panukala tulad ng EIP-4844 (Proto-Danksharding) na nagmumungkahi ng konsepto ng “mga blob” — isang bagong uri ng imbakan ng datos na mas mura at panandalian lamang, na idinisenyo para lamang sa mga rollup. Ngunit, kahit may mga blob, may limitasyon pa rin sa dami ng datos na maaari mong ipasok sa network nang hindi napapabigat ang mga node. Kapag napuno ang DA layer, tumataas nang malaki ang gastos sa paggamit ng mga Layer 2 na iyon dahil nag-uunahan ang mga rollup na makapasok sa limitadong espasyong iyon upang mai-post ang kanilang mga batch. Nagbibigay-daan ito sa isang merkado kung saan ang presyo ng isang transaksyon sa ilang murang L2 ay direktang nakadepende sa congestion ng isang mamahaling L1. Ito ay isang tradeoff sa pagitan ng pagtitiwala sa seguridad at gastos ng pag-secure (pag-post sa L1) at ng aktwal na paggamit.

## Ang Pasanin ng Kasaysayan: Paglawak ng Estado at Imbakan

Ang isa sa pinakamahalaga — at kasingdalas na nalilimutang — problema ay ang "state bloat". Ang isang blockchain ay binubuo ng magkakaparehong kopya ng bawat transaksyong naganap kailanman. Habang mas maraming tao ang gumagamit ng network, lumalawak ang kasaysayang ito. Ngunit hindi lamang ito ang kasaysayan; ito ang “estado” (state) — ang kasalukuyang balanse ng bawat account at pagmamay-ari ng bawat smart contract. Ang isang node ay kailangang makapag-verify ng isang transaksyon upang malaman nito kung ano ang kasalukuyang estado. Kailangan nitong matiyak kahit papaano na si Alice ay tunay ngang nagmamay-ari ng 10 token na nais niyang ipadala kay Bob. Habang lumalaki ang estado, mas maraming RAM at SSD storage ang kinakailangan upang mabilis itong ma-access.

![](https://netts.io/blog/articles/optimization-of-blockchain-main-bottlenecks/images/1-3.png)

Kung ang estado ay masyadong malaki para magkasya sa hardware na pang-karaniwang mamimili, tanging malalaking datacenter lamang ang may kakayahang magpatakbo ng mga node. Nakakasama ito sa decentralization. Ang pag-optimize nito ay napakahirap. Hindi mo basta-basta maaaring alisin ang lumang datos, dahil nakadepende ito sa buong kasaysayan ng chain pabalik sa Genesis block. Nag-eeksperimento ang mga developer sa “mga stateless client” at "state expiry”, na nagtatala ng lumang datos at gumagamit na lamang ng sapat na patunay para dito. Ngunit ang mga ito ay mga advanced na cryptographic na solusyon na nangangailangan ng maraming taon bago maipamahagi nang ligtas. Patuloy nating nilalabanan ang pag-iimbak ng labis na datos.

Bawat contract na iyong ini-deploy, bawat token na iyong mina-mint ay pabigat na kailangang dalhin ng isang node magpakailanman. Ang pagkonsumong ito ng mapagkukunan ang dahilan kung bakit ang ilang network ay nagpapatupad ng mga resource model tulad ng Energy at Bandwidth. Maaaring kailanganin ng mga user na mag-recharge ng mga Energy point upang makipag-ugnayan sa isang smart contract nang hindi gumagastos ng mga token, o kumuha ng TRON Energy kung saan ang mga transaksyon ay napoproseso nang mas mabilis. Ang mga modelong ito ay isang pagsusumikap na maningil nang tama para sa pasanin sa network - ang mga taong gumagamit ng estado ay dapat magbayad upang suportahan ito. Kung walang ganitong mga mekanismo, ang “tragedy of the commons” ay magreresulta sa isang chain na mapupuno at magiging hindi na magagamit.

## Consensus at ang Overhead Nito sa Pamamagitan ng mga Consensus Mechanism

Sa puso ng bawat blockchain ay isang consensus mechanism — kung paano ang libu-libong estranghero ay maaaring sama-samang sumang-ayon sa iisang katotohanan. Pag-usapan man ang PoW o PoS, palaging may kasamang antas ng komunikasyon at kompyutasyon ang consensus. Sa PoW, ang pagbagal ay higit sa lahat dahil sa kung gaano kalaking enerhiya at hardware ang kinakailangan upang ma-secure ang network. Ang hamon sa pagsasaayos ng difficulty ay panatilihin ang pagdating ng mga block sa bilis na hindi masyadong mabilis (seguridad) o masyadong mabagal (bilis). Para sa PoS, na matipid sa enerhiya, ang bottleneck ay lumilitaw sa anyo ng communication overhead.

Kailangang palaging magpalitan ng mga set ng mensahe ang mga validator bilang patunay kung paano dapat ituring na valid ang mga block. Habang dumarami ang mga validator upang palaguin ang decentralization, ganoon din ang bilang ng mga mensahe (exponentially). Ang “daldalang” (chatter) ito ay maaaring mag-overload sa network. Isang napakalaking gawain ang i-optimize ang consensus algorithm upang kumportable itong makapag-scale sa libu-libong validator nang hindi bumabagsak ang bilis ng transaksyon sa gapang na antas. Gumagamit ito ng mga pambihirang matematika at mga pamamaraan ng “signature aggregation” (katulad ng mga BLS signature) upang pagsama-samahin ang libu-libong boto sa iisang maliit na piraso ng datos. Bukod dito, ang “finality” ng isang transaksyon — ang katiyakan na hindi na ito mababawi — ay kadalasan ding nagiging probabilistic.

Sa maraming chain, kailangan mong maghintay ng ilang block upang makasiguro. Ang time-lag na ito ay dahil sa pagsasama-sama ng consensus ng network. Isa itong feature para sa seguridad, hindi isang bug, ngunit maaari itong magmukhang isang bottleneck sa user na umaasa ng kumpirmasyon. Bukod pa rito, ang isyu ng "Nothing at Stake" sa mga naunang disenyo ng PoS ay nangailangan ng mga komplikadong mekanismo ng "slashing" upang parusahan ang maling gawi, kaya may karagdagang lohika na kailangang iproseso para sa bawat block. Ang isa pang nakatagong bottleneck ay ang “client diversity.” Kapag ang lahat ay nagpapatakbo ng parehong software client (halimbawa, Geth), ang isang solong bug ay maaaring magpabagsak sa buong network. Mahalagang hikayatin ang pagkakaiba-iba sa ecosystem pagdating sa mga client upang magbigay ng katatagan, ngunit nagdaragdag ito ng maraming pasanin sa pagbuo at pagpapaunlad.

## Ang Nakatagong Buwis: MEV at mga Bottleneck sa Execution

Ang Virtual Machine (VM): Ito ang kapaligiran ng pagpapatupad para sa mga smart contract. Ang Ethereum Virtual Machine (EVM) ang pamantayan, ngunit hindi ito idinisenyo para sa high-throughput parallel operations noong una. Tumatanggap ito ng mga transaksyon nang isa-isa at pinoproseso ang mga ito sa pagkakasunod-sunod ng pagkatanggap. Kung ang isang transaksyon ay talagang kumplikado at tumatagal bago makompyuta, ang lahat ay kailangang maghintay sa pila. Katumbas ito ng iisang checkout counter sa isang grocery store. Sinusubukan ng mga makabagong blockchain na makamit ang “parallel execution,” kung saan ang mga transaksyong hindi nagkakaroon ng salungatan (halimbawa, si Alice na nagbabayad kay Bob at si Charlie na nagbabayad kay Dave) ay maaaring iproseso nang sabay-sabay ng iba't ibang CPU core. Ngunit minsan ay mas madali itong sabihin kaysa gawin. Isa itong mapanghamong problema sa computer science na tukuyin kung aling mga transaksyon ang nagkakaroon ng interference sa real time.

![](https://netts.io/blog/articles/optimization-of-blockchain-main-bottlenecks/images/1-4.png)

At bukod sa bilis ng execution, nariyan ang bottleneck ng MEV. Dahil ang karamihan sa mga transaksyon ay makikita kapag naisumite na sa mempool, ang mga advanced na bot ay maaaring mag-front-run o mag-sandwich sa mga transaksyon ng mga user para kumita. Ito ay sa katunayan isang nakatagong buwis sa bahagi ng mga user, na nagdudulot ng mas masamang exchange rate at mga nabigong transaksyon. Pinupuno nito ang network ng spam mula sa mga bot na naglalaban-laban. Ang solusyon sa MEV ay isa sa mga matitinding problema sa pag-optimize ng blockchain. Ang mga pamamaraan tulad ng “proposer-builder separation” ay naglalayong ihiwalay ang mga salik nang maayos, ngunit nananatili itong isang patuloy na kawalan ng kahusayan na nagreresulta sa hindi magandang karanasan ng user.

## Ang Watak-watak na Mundo: Mga Hamon sa Interoperability

Sa paglipat patungo sa multi-chain na mundo, isang bagong bottleneck ang lumitaw — ang interoperability. Nakagawa tayo ng maliliit na pulo ng halaga. Ang paglilipat ng mga asset mula sa Ethereum patungo sa Solana o mula sa Bitcoin patungo sa isang Layer 2 network ay nangangailangan ng “mga bridge.” Ang mga bridge na ito ang mahihinang punto sa ecosystem, na madaling ma-hack at ma-exploit. Ang "pag-wrap" ng mga token ay isang karagdagang patong ng pagiging kumplikado at potensyal na panganib. Ang bottleneck sa aspetong ito ay ang kawalan ng pangkalahatang protocol sa komunikasyon. Bawat blockchain ay nagsasalita ng ibang wika at may ibang consensus sa oras at sa finality.

Ang pagbuo ng isang “trustless” na bridge — isang hindi umaasa sa isang sentralisadong custodian — ay napakahirap sa aspeto ng matematika. Nangangailangan ito ng isa sa dalawang chain upang magpatakbo ng isang “light client” (halimbawa, pag-verify ng mga header at proof). Ito rin ay nangangailangan ng matinding kompyutasyon at datos. Bukod sa abala ng paglilipat ng liquidity sa iba't ibang chain, pinaghihiwa-hiwalay nito ang merkado at ginagawa itong hindi mahusay. Naiipit ang mga user sa isang chain nang walang madaling paraan upang mag-refill ng TRON Energy at ilipat ang kanilang mga asset kung saan may pinakamagandang yield, maliban kung dadaan sila sa masalimuot na web ng mga protocol na may mataas na panganib. Bukod dito, ang “atomic composability” — ang ideya na maaari akong makipagtransaksyon sa maraming protocol nang sabay-sabay sa isang transaksyon lamang — ay nawawala kapag lumipat ka sa pagitan ng mga chain. Hindi ka maaaring kumuha ng flash loan sa Chain A upang mag-arbitrage sa kakaibang nangyayari sa Chain B nang walang malaking panganib at pagkaantala.

## Ang Pantaong Salik: Governance at Pagiging Maaaring I-upgrade

Sa huli, ang pinakanakakadismayang bottleneck sa lahat ay maaaring ang pantao: ang governance. Ang mga blockchain ay software, at ang software ay kailangang i-update. Ngunit sa isang desentralisadong network, paano magpapasya kung kailan at paano magaganap ang pag-upgrade? Ang pag-iskedyul ng isang “hard fork,” isang pag-upgrade na hindi backward compatible, ay kinabibilangan ng kasunduan sa pagitan ng mga developer, ng mga nagpapatakbo ng mga node sa network, at ng mga miner/validator gayundin ng pangkalahatang consensus ng komunidad. Kung may hindi pagkakasundo, maaaring magbago ng direksyon ang chain, tulad ng nangyari sa Ethereum at ang sumunod nitong pagkahati ng chain sa dalawang coin na umiiral ngayon: Ethereum at Ethereum Classic.

Ang hangaring ito para sa panlipunang kasunduan ay humahadlang hindi lamang sa pagbabago kundi maging sa inobasyon. Ang isang tech company na nakabatay sa platform ay maaaring maglabas ng update sa mga server nito sa loob lamang ng ilang minuto. Kung ang isang blockchain ay kinakailangang sumunod sa anumang function f, kahit para sa pinakamaliit na function ay nagiging imposible para sa chain na mabilis na magpatupad ng mga bagong pagpapabuti. Ang “governance minimization” na ito ay madalas na layunin, ngunit sa mga unang araw, ang aktibong pamamahala ay mahalaga upang ayusin ang mga bug at pahusayin ang protocol. Ang trade-off sa pagitan ng mabilis na pagkilos at pagbasag ng mga bagay laban sa katatagan at immutability ay palaging pinagmumulan ng alitan. Ito ang maaaring magpalit sa ilan sa pinakamahahalagang pag-optimize, tulad ng pagpapalaki ng block size o maging ng pagbabago sa mekanismo ng fee, tungo sa mga pulitikal na labanan na nagpapabagal sa pag-unlad nang maraming taon.

## Konklusyon

Ang mga bottleneck ng blockchain — scalability, data availability, state bloat, consensus overhead, bilis ng execution, MEV, interoperability, at governance ay hindi mga basta-bastang hangganan. Ang mga ito ay resulta ng isang ambisyosong hangarin na bumuo ng isang trustless, desentralisado, at ligtas na pandaigdigang computer. Bawat pag-optimize ay may kaakibat na trade-off. Ang pagpapalaki ng block size ay nakakasama sa decentralization. Ginagawang mas mahirap na hamon ng sharding ang seguridad. Ang parallel execution ay may panganib ng hindi pagkakatugma ng estado. Kaya naman kahanga-hangang makita ang antas-2026 na pagsulong sa Layer 2 rollups, data availability sampling at mingling, at zero-knowledge snarks pati na rin ang mga proof sa pangkalahatan na naging reyalidad sa kasalukuyan ng mga taong nag-isip "out of the box" sa loob ng ilang taon.

Ngunit salamat sa katalinuhan ng tao, patuloy tayong unti-unti ngunit tiyak na umaangat sa ibabaw ng mga pisikal at lohikal na limitasyong ito. Gayunpaman, dapat maunawaan ng mga user na ang “friction” na kanilang nararamdaman ay ang kapalit ng paggamit sa isang sistemang nakabatay sa mga batas ng pisika at mahigpit na consensus, sa halip na pagtitiwala sa isang sentral na awtoridad. Kung paanong maaaring kailanganin mo ang TRON Energy upang matustusan ang mga gastusin sa transaksyon sa isang distributed network, ang industriya ay nangangailangan ng patuloy na suplay ng bagong inobasyon upang mai-scale ang mga sistemang ito para sa buong mundo.

![](https://netts.io/blog/articles/optimization-of-blockchain-main-bottlenecks/images/1-5.png)

Para sa mga taong nakikitungo sa mga masasalimuot na proseso ng pagkuha ng mga resource sa TRON, maaari silang gumamit ng mga tool tulad ng Netts Energy Charge Bot. Ang mga charger ay nakakakuha ng Energy para sa paglilipat at pinaparentahan ($) sa mga user, kapag naglilipat ng mga tether sa Charge_bot (Telegram), sa ganitong paraan ay nababawasan ang mga fee mula sa mga paglilipat ng USDT. Kailangan lamang pumili ng wallet ng mga user at magdeposito ng pera rito gamit ang TRX, pagkatapos ay magagamit nila ang intermediary currency upang mag-refuel ng Energy sa loob ng isang oras, upang hindi mo na kailangang magsunog ng malalaking halaga ng TRX kapag naglilipat. Pinapadali nito nang bahagya ang proseso: pumili lamang ng wallet, i-charge ito, at gawin ang iyong paglilipat, kung saan posibleng kalkulahin din ng bot ang tinatayang mga nagamit na resource. Isa itong maliit ngunit mahalagang tool upang mapahusay ang UX sa isang kapaligiran kung saan mahalaga ang bawat resource!