Utafiti huu unatengeneza jukwaa linaloweza kukaguliwa la kurekodi linaloitwa Proof-of-Charge, ambalo linawezesha risiti inayoundwa mwishoni mwa kipindi cha kuchaji gari la umeme kutohifadhiwa tu kama rekodi ya hifadhidata, bali pia kuruhusu kubainika kwa njia huru ikiwa ilibadilishwa baadaye. Mfumo hubadilisha kipindi cha kuchaji kuwa risiti ya kideterministi, huhesabu muhtasari wa maudhui ya risiti kwa SHA-256, huunganisha vipimo vya mita vilivyopangwa kwa wakati na mzizi wa Merkle, na hujumuisha risiti nyingi chini ya mzizi mmoja wa Merkle batch huku ukiandika kwenye blockchain ahadi hiyo fupi pekee. Taarifa za kina za kuchaji na bili huhifadhiwa nje ya mnyororo katika PostgreSQL.

Prototipu ilitekelezwa kwa kutumia FastAPI, PostgreSQL, Python, Solidity na mnyororo wa maendeleo wa ndani wa Anvil unaooana na Ethereum. Kila mzigo wa kazi wa risiti 10, 50, 100, 500 na 1000 ulipimwa mara kumi; katika jumla ya utekelezaji 50 wenye vipimo, vitambulisho vya risiti zilizoombwa, zilizozalishwa, zilizohifadhiwa, zilizowekwa kwenye batch, zilizothibitishwa na zilizosafirishwa vilipatanishwa; ukaguzi wa mzizi wa batch na ulinganisho wa blockchain ya ndani ulifaulu. Ucheleweshaji wa wastani wa kuchakata risiti uliripotiwa kuwa katika kiwango cha 7,152–7,853 ms/risiti kwa mizigo iliyojaribiwa, huku throughput ya wastani ikiwa 127,54–141,23 risiti/s.

Jambo moja linalovutia katika utafiti ni kwamba blockchain haitumiki kuhifadhi rekodi nzima ya kuchaji, bali kama kiini kidogo cha ukaguzi wa uadilifu kinachoweza kulinganishwa kutoka nje. Kitambulisho cha kituo cha kuchaji, data ya mtumiaji, sampuli za mita, bei na maelezo ya settlement hubaki nje ya mnyororo, huku mzizi mmoja wa batch wa risiti nyingi ukiweza kuwakilishwa kwa muamala mmoja wa blockchain. Katika majaribio ya ndani, kitendo cha kuankisha batch kilitumia vitengo 143.329 vya gas kwa risiti 10 na vitengo 143.365 vya gas kwa risiti 1000; ukaribu huu unatokana na ukweli kwamba kinachotumwa kwenye mnyororo si risiti zenyewe bali mzizi wa ukubwa thabiti.

Hata hivyo, mfumo unalenga kufanya mabadiliko yaliyofanywa baada ya data kurekodiwa yaonekane; hauwezi kuthibitisha kwamba tukio la kuchaji lililozalishwa vibaya, kughushiwa au kutotumwa kabisa kwenye mfumo kabla ya kuundwa kwa ahadi ya kwanza ya kuaminika ya kriptografia ni la kweli. Utafiti haukutekeleza sahihi halisi ya kifaa cha kuchaji, sahihi ya kidijitali katika kiwango cha mita, mnyororo wa vyeti, muhuri wa muda unaoaminika, mzunguko wa maisha wa ufunguo, finality kwenye mtandao wa blockchain wa umma au data halisi ya uendeshaji ya OCPP/OCPI. Kwa hiyo, Proof-of-Charge si mfumo wa upimaji unaohakikisha kwamba data ya chanzo ni sahihi kimwili; ni prototipu inayofanya uadilifu na uthabiti wa rekodi baada ya kuundwa kwake uweze kukaguliwa.

Kwa mtazamo wa Uturuki: Kwa kiwango cha dhana, usanifu huu ni mbinu ya jumla ya kurekodi na kukagua ambayo inaweza pia kuzingatiwa katika majukwaa ya kuchaji magari ya umeme nchini Uturuki; hata hivyo, utafiti haukujaribu waendeshaji wa kuchaji nchini Uturuki, miundombinu ya mita ya ndani, itifaki halisi za kuchaji, mifumo ya malipo na upatanisho au mazingira ya uendeshaji ya ndani. Aidha, thamani zilizoripotiwa za ucheleweshaji, throughput na miamala ya blockchain haziwezi kuhamishwa moja kwa moja kwenye miundombinu ya uzalishaji nchini Uturuki. Kwa matumizi halisi, uthibitishaji wa ziada unahitajika kwenye vifaa vya kuchaji vya ndani, data halisi ya mita, usimamizi wa utambulisho na funguo, miundombinu ya mtandao, ukubwa wa hifadhidata na michakato ya upatanisho wa kiutendaji.

Tatizo kuu la utafiti ni lipi?

Kuchaji gari la umeme si suala la kupeleka nishati kwenye betri ya gari pekee. Katika kipindi cha kuchaji cha umma, dereva, mwendeshaji wa kituo cha kuchaji, mtoa huduma wa e-mobility, jukwaa la roaming, mtoa huduma wa malipo na wahusika wengine wa mfumo wa nishati wanaweza kuwepo katika mnyororo mmoja wa rekodi ya kidijitali. Usomaji wa mita, mihuri ya muda, ada, vitambulisho vya miamala na ankara ya mwisho huenda vikahitaji kuchunguzwa tena baadaye kwa mzozo wa malipo au ukaguzi.

Tatizo linalolengwa na utafiti ni hili: inawezekanaje kukagua kwa njia huru kwamba risiti ya mwisho iliyo katika hifadhidata imeendelea kuhusishwa kweli na rekodi ileile ya data ya mita iliyopangwa kwa wakati iliyotumika wakati risiti ilipoundwa na kwamba haijabadilishwa baadaye?

Itifaki kama OCPP na OCPI zinaunga mkono ubadilishanaji wa data kati ya miundombinu ya kuchaji na backend au watoa huduma tofauti. Hata hivyo, pengo ambalo watafiti wanasisitiza ni kwamba uhamishaji wa data wenyewe si utaratibu huru wa uthibitishaji unaothibitisha uadilifu wa risiti kwa muda mrefu.

Proof-of-Charge inamaanisha nini?

Katika utafiti huu, Proof-of-Charge ni dhana pana kuliko thamani moja ya hash. Neno hili linaeleza mnyororo mzima wa uthibitishaji unaounganisha risiti iliyokamilika ya kuchaji EV na rekodi za mita zilizopangwa kwa wakati, uanachama wa batch na ahadi ya kriptografia iliyoankishwa kwenye blockchain.

Mtiririko mkuu ni huu:

Kwa nini rekodi yote haiandikwi moja kwa moja kwenye blockchain?

Watafiti hawatumii blockchain badala ya hifadhidata ya programu. Kipindi kamili cha kuchaji kinaweza kujumuisha vitambulisho vya mtumiaji na EVSE, sampuli za mita, mihuri ya muda, maelezo ya ada na thamani za settlement. Kuhifadhi maelezo yote haya kwenye mnyororo kunaweza kuongeza mzigo wa uhifadhi na gharama za miamala, na pia kusababisha data nyeti kufichuliwa bila sababu.

Kwa hiyo jukwaa hutumia muundo mseto:

• Off-chain: Rekodi kamili za vipindi, thamani za mita, risiti, uanachama wa batch na historia ya uthibitishaji huhifadhiwa katika PostgreSQL.
• On-chain: Mzizi mdogo wa Merkle batch unaowakilisha risiti nyingi pekee ndio huhifadhiwa.

Blockchain hapa si “hifadhidata inayobeba ukweli wote”, bali ni rejea ya nje ya kriptografia inayoweza kulinganishwa baadaye na rekodi ya ndani.

Kwa nini risiti ya kikanoni ni muhimu?

Katika kukokotoa hash ya kriptografia, nyaraka mbili za JSON zenye maana sawa ya kisayansi au kibiashara zikikuwa tofauti katika kiwango cha byte zitazalisha hash tofauti. Mpangilio wa funguo, umbo la Unicode, uandishi wa eneo la wakati, namna ya kuzungusha namba au nafasi zisizohitajika zikibadilika, hash pia inaweza kubadilika. Watafiti walifafanua wasifu wazi wa ukanonishaji uitwao poc-c14n-v1 ili kuzuia tatizo hili.

Katika wasifu huo, risiti mpya husawazishwa kama JSON fupi ya UTF-8; funguo za vitu hupangwa kulingana na code point ya Unicode, mpangilio wa array huchukuliwa kuwa na maana, maandishi hunormishwa hadi Unicode NFC, mihuri ya muda hubadilishwa kuwa muundo wa UTC, na kiasi cha nishati/bei/settlement huwakilishwa kama mifuatano yenye tarakimu tatu za desimali kwa kutumia ROUND_HALF_UP. Sifuri hasi hubadilishwa kuwa 0.000.

Katika hali ya kukosekana kwa uga wa lazima, thamani ya null, uga wa ziada, timestamp isiyo na eneo la wakati, namba isiyo finite, duplicate JSON key, wasifu usiojulikana au algoritimu isiyoungwa mkono, mchakato umeundwa “fail closed”.

Watafiti wanaripoti kwamba utekelezaji wa Python 3.13.3 na Node.js v23.10 ulizalisha mfuatano uleule wa byte za UTF-8 na matokeo yale yale ya SHA-256 kwa vekta iliyobainishwa ya upatanifu. Jaribio hili linathibitisha tu jozi ya Python–JavaScript iliyochunguzwa; si ushahidi wa upatanifu wa jumla kwa kila lugha ya programu au kila kisawazishaji cha JSON.

Kipindi cha kuchaji kinawakilishwaje kihisabati?

Katika utafiti, kipindi cha kuchaji kinafafanuliwa kwa muundo wa jumla ufuatao:

\[ S=\{sid,uid,evse,tx,t_s,t_e,M,P,type\} \]

Hapa sid ni kitambulisho cha kipindi, uid kitambulisho cha mtumiaji, evse kitambulisho cha kituo cha kuchaji, tx kitambulisho cha muamala, \(t_s\) na \(t_e\) ni nyakati za kuanza/kumaliza, \(M\) ni data ya mita iliyopangwa, \(P\) ni muundo wa bei, na type huonyesha ikiwa kipindi ni cha kuchaji pekee, kutoa nishati pekee au cha pande mbili.

Mtiririko wa mita:

\[ M=\{m_1,m_2,\ldots,m_n\} \]

uko katika umbo hili. Kila \(m_i\) hubeba muhuri wa muda na vipimo vinavyohusiana na nishati.

Hesabu ya nishati kwa V2G inamodeliwaje?

Risiti inaweza kuwakilisha si tu nishati iliyohamishwa kwenda kwenye gari, bali pia nishati iliyorudishwa kutoka kwenye gari. Muhtasari wa nishati:

\[ E=\{E_{\mathrm{import}},E_{\mathrm{export}},E_{\mathrm{net}}\} \]

hufafanuliwa, na invariant ya msingi ni:

\[ E_{\mathrm{net}}= E_{\mathrm{import}}-E_{\mathrm{export}} \]

Katika kipindi cha kuchaji pekee, export ni sifuri. Katika kipindi cha kutoa nishati pekee, net energy inaweza kuwa hasi. Katika kipindi cha pande mbili, risiti ileile inaweza kujumuisha nishati iliyoingizwa na nishati iliyorejeshwa.

Kwa settlement, maelezo ya maandishi ya chanzo yanafafanua gharama ghafi ya import \(C_{\mathrm{import}}\), mkopo ghafi wa export \(C_{\mathrm{export}}\) na kiasi net \(C_{\mathrm{net}}\), na kutumia uhusiano:

\[ C_{\mathrm{net}}= C_{\mathrm{import}}-C_{\mathrm{export}} \]

.

Onyo kuhusu alama za chanzo: Katika Sehemu 4.3 ya utafiti, wakati nyuga hizi za gharama zinaelezwa, Equation (6) huandika tena vigezo vya nishati. Kwa hiyo, kuna kutokulingana kwa alama ndani ya chanzo kati ya uwasilishaji wa Equation (6) na maelezo ya gharama yaliyo mara moja chini yake. Verianla haibadilishi usemi huu kimya kimya.

Hash ya risiti inalinda nini?

Baada ya risiti ya kikanoni \(R\) kuundwa:

\[ h_R=H(R) \]

hukokotolewa. Katika prototipu, \(H\) ni SHA-256. Ikiwa muhuri wa muda, kiasi cha nishati, uga wa bei, kitambulisho au mzizi wa Merkle wa mita katika risiti hubadilika, hash inayokokotolewa upya pia hubadilika.

Utaratibu huu hauthibitishi kwamba “taarifa katika risiti ni sahihi katika ulimwengu wa kimwili”. Kinachothibitishwa ni ikiwa maudhui fulani ya kikanoni yalibadilishwa baada ya hash kuundwa.

Kwa nini data ya mita pia ina mzizi wake wa Merkle?

Kuhash jumla ya mwisho ya nishati pekee hakuungi moja kwa moja mlolongo wa vipimo uliotumika kufikia jumla hiyo. Kwa hiyo, kila sampuli ya mita huhashwa kwanza:

\[ h_i=H(m_i) \]

na kisha:

\[ root_M= MerkleRoot(h_1,h_2,\ldots,h_n) \]

hukokotolewa. Kubadilisha, kufuta, kupanga upya au kuingiza sampuli nyingine baadaye kwenye rekodi ya mita kunaweza kubadilisha mzizi unaokokotolewa upya.

Sampuli hupangwa kwa timestamp, na import na export huchukuliwa kama mita limbikizi za mwelekeo katika kWh. Thamani huzungushwa kwa usahihi wa 0,001 kWh, na thamani ya mita limbikizi inayopungua hukataliwa kwa kuchukuliwa kama reset inayowezekana au uharibifu wa data.

Hata hivyo, prototipu haikadirii sampuli ya mita iliyokosekana, haisahihishi reset ya mita kiotomatiki, haisawazishi mkengeuko wa saa, wala haibadilishi kitengo ambacho chanzo hakijataja. Muhimu zaidi, ikiwa sampuli ya mita haikutumwa kabisa kwenye mfumo kabla ya ahadi ya kwanza ya kuaminika, mti wa Merkle pekee hauwezi kujua kwa njia huru kwamba sampuli hiyo haipo.

Kwa nini mzizi wa Merkle wa batch unatumika mara ya pili?

Mti wa kwanza wa Merkle unawakilisha mlolongo wa mita wa kipindi kimoja, huku mti wa pili wa Merkle ukiwakilisha risiti nyingi:

\[ B=\{h_{R1},h_{R2},\ldots,h_{Rk}\} \]

na:

\[ root_B= MerkleRoot(h_{R1},h_{R2},\ldots,h_{Rk}) \]

hupatikana. Badala ya kutuma muamala tofauti kwenye blockchain kwa kila risiti, ni \(root_B\) pekee inayotumwa.

Katika batch mpya, wasifu wa poc-batch-merkle-v1 hutumiwa. Wasifu huo hufunga siku ya UTC ya batch, muda, kanuni ya kupanga, idadi ya leaf na muktadha wa uundaji wa mti wa Merkle kwenye ahadi. Rekodi hupangwa kideterministi kulingana na muda wa kuanza wa UTC ulionormishwa, kitambulisho cha kipindi kilichonormishwa kwa NFC na byte za hash ya risiti.

Wasifu hukataa duplicate session ID, duplicate receipt hash, duplicate leaf encoding, hash iliyoharibika na faharasa batili. Ikiwa kuna idadi isiyo shufwa ya nodi katika kiwango cha Merkle, nodi ya mwisho huunganishwa na yenyewe.

Inathibitishaje kwamba risiti imo ndani ya batch?

Mfumo huzalisha JSON membership proof huru inayowezesha kuthibitisha uanachama wa risiti moja ndani ya batch bila kushiriki batch nzima. Katika mfano wa kideterministi wenye leaf 1000, watafiti waliripoti:

• kina cha mti wa Merkle kuwa 10,
• idadi ya hash ndugu kuwa 10,
• ukubwa wa JSON proof iliyosawazishwa kuwa 2064 byte,
• muda wa kutengeneza proof kuwa takriban 0,060 ms,
• muda wa kuthibitisha proof kuwa takriban 0,057 ms

. Nyakati hizi ni vipimo vya uchunguzi katika mazingira yale yale ya jaribio la ndani na hazipaswi kutafsiriwa kama utendaji wa jumla wa blockchain proof.

Kwa nini uthibitishaji una tabaka?

Ukaguzi mmoja wa hash hauwezi kubainisha kila aina ya kutokulingana katika hifadhidata kwa usahihi uleule. Kwa hiyo, utafiti hutumia nyuso tano za ukaguzi zinazokamilishana:

1. Uthibitishaji wa risiti: JSON ya kikanoni huhashwa upya.
2. Uthibitishaji wa mita: meter Merkle root hukokotolewa upya kutoka kwenye safu za mita zilizonormishwa.
3. Ukaguzi wa hifadhidata: Risiti iliyoundwa upya kutoka kwenye kipindi, JSON iliyohifadhiwa na safu zilizonormishwa hulinganishwa.
4. Uthibitishaji wa batch: Snapshot ya uanachama na batch root hukokotolewa upya.
5. Uthibitishaji wa on-chain: Batch root ya ndani hulinganishwa na mzizi unaosomwa kutoka kwenye mkataba wa blockchain.

Muundo huu husaidia kubainisha ni katika tabaka gani la rekodi uharibifu umetokea badala ya kusema tu “uthibitishaji umeshindwa”.

Blockchain haitoi vipengele gani vya usalama?

Watafiti wanaweka mipaka wazi kwa wigo wa blockchain. Katika prototipu ya sasa, uadilifu wa maudhui, ukokotoaji upya wa mita, uthibitishaji wa batch, database audit na ulinganisho wa mzizi wa on-chain vimetekelezwa. Hata hivyo, uthibitishaji wa utambulisho na uhalisi wa chanzo umeachwa kwa hatua ya uzalishaji.

Kwa usambazaji wa kweli, chanzo kinapendekeza udhibiti wa ziada kama sahihi za kidijitali, minyororo ya vyeti, usimamizi wa funguo unaoaminika, revocation, trusted timestamp, udhibiti wa publisher aliyeidhinishwa, ulinzi dhidi ya replay, contract governance, mbinu za faragha na upatanisho na external authoritative session registry.

Kwa hiyo, “ipo kwenye blockchain” na “kipimo ni halisi kwa hakika” si madai sawa ya kisayansi.

Utafiti unasema nini, na hauseni nini?

Matokeo yanayoungwa mkono na utafiti:

• Uundaji wa risiti ya kuchaji EV ya kideterministi na uthibitishaji wa kuhash upya umetumika.
• Rekodi za mita zilizopangwa kwa wakati zimeweza kufungwa kwa mzizi wa Merkle katika kiwango cha kipindi.
• Risiti zimekusanywa chini ya mzizi wa Merkle batch na kuwakilishwa kwa muamala mmoja wa blockchain.
• Katika jumla ya marudio 50 yenye vipimo kwa risiti 10–1000, ukaguzi wote wa correctness uliobainishwa ulifaulu.
• Tofauti zote saba zilizodhibitiwa za post-finalization ziligunduliwa katika tabaka husika za uthibitishaji zilizobainishwa mapema.
• Rekodi za sintetik za charge-only, discharge-only na bidirectional ziliwakilishwa kwa usanifu uleule wa msingi wa risiti/uthibitishaji.

Matokeo ambayo utafiti hauungi mkono au haukujaribu:

• Haithibitishi kwamba data inayotoka kwenye kituo halisi cha kuchaji ni sahihi kimwili.
• Haitambui kiotomatiki kipindi kilichoghushiwa au kutorekodiwa kabisa kabla ya ahadi ya kwanza ya kriptografia.
• Haijajaribiwa katika mfumo halisi wa uzalishaji wa OCPP au OCPI.
• Kifaa hai cha V2G au settlement ya soko la nishati haikujaribiwa.
• Haipimi ucheleweshaji, fee au utendaji wa finality kwenye mtandao wa umma wa Ethereum/EVM.
• Haitumii Digital signature, PKI, issuer authentication au trusted timestamp.
• Matokeo hayawezi kujumlishwa moja kwa moja kutoka mazingira moja ya majaribio ya Apple M1 Max hadi maunzi mengine.
• Ada za gas za Anvil ya ndani haziwezi kutumiwa kama gharama halisi ya mtandao.

Mbinu na Matokeo ya Utafiti

Mazingira ya jaribio

Kwa kila mzigo wa kazi, utekelezaji mmoja wa warm-up ulifanywa na kufuatiwa na marudio kumi yenye vipimo. Jumla ya mchanganyiko 50 wa workload–seed uliopimwa uliwekwa kwa mpangilio wa nasibu kwa kutumia orchestration seed 20260801. Utafiti haukuondoa uchunguzi wowote kama outlier.

Utendaji wa kuchakata risiti

Ucheleweshaji wa wastani haukuonyesha ongezeko la upande mmoja la monotoniki kadri mzigo wa kazi ulivyoongezeka. Kwa sababu vipindi vya kujiamini vilipishana kwa kiasi kikubwa, utafiti hauhitimishi, kwa mfano, kwamba risiti 50 ni intrinsically za haraka kuliko risiti 100. Tafsiri finyu zaidi ni kwamba katika mazingira moja ya ndani yaliyotumika, ucheleweshaji wa wastani wa pipeline kwa kila risiti uliendelea kuwa takriban katika bendi ileile.

Tail latency, hata hivyo, ilionyesha tabia iliyo wazi zaidi. Katika mzigo wa risiti 1000, p99 latency ilifikia 15,076 ms, wakati katika mzigo wa risiti 10 ilikuwa 11,032 ms. Kwa hiyo, kuangalia wastani pekee hakuonyeshi kikamilifu tabia ya tail latency katika mizigo mikubwa.

Ni nini kinachotumia muda mwingi katika pipeline?

Katika mzigo wa risiti 1000, muda wa wastani uliogawanywa kwa hatua ni kama ifuatavyo:

Katika utekelezaji wa utafiti, kipengele kilichotawala muda wa pipeline kwa kila risiti kilikuwa PostgreSQL persistence. Muda wa kuunda risiti na kukokotoa Merkle ya mita ulikuwa mdogo sana ukilinganishwa na huo. Watafiti hawakubadilisha njia iliyopo ya per-receipt persistence kuwa bulk insert kwa lengo la kuonyesha matokeo bora zaidi.

Kuankisha batch kwenye blockchain kulipanukaje?

Matumizi ya gas yalibadilika kwa kiasi kidogo sana kati ya risiti 10 na 1000. Sababu ni kwamba si risiti zote zinazotumwa kwenye mkataba wa Solidity, bali mzizi mmoja wa Merkle batch wa ukubwa thabiti pamoja na metadata inayohusiana.

Kupungua kwa thamani za wei kwenye jedwali kadri mzigo unavyoongezeka hakupaswi kutafsiriwa kama “batch kubwa ni nafuu kabisa kwenye blockchain”; transaction fee hutegemea zao la matumizi ya gas na effective gas price ya muamala huo wa ndani. Zaidi ya hayo, majaribio haya yalifanywa kwenye mnyororo wa ndani wa Anvil unaotumia automatic mining. Thamani hizi si ada halisi za Ethereum, Layer-2 au mitandao mingine ya umma.

Uhusiano mkuu wa upanuzi katika mbinu ya batch ya utafiti ni:

\[ C_{\mathrm{session}} = \frac{C_{\mathrm{tx}}}{N_{\mathrm{receipts}}} \]

. Ikiwa muamala uleule wa batch unashughulikia risiti nyingi zaidi, gharama ya kuankisha kwa ufanisi hupungua si kwa kila muamala, bali kwa kila risiti inayofunikwa.

Majaribio saba ya kubadilisha data kwa udhibiti yalionyesha nini?

Hali zote saba zilionyesha tabia iliyobainishwa mapema, na baada ya kila hali hifadhidata ilirudishwa kwenye hali ya awali kwa savepoint rollback. Katika jaribio la T7, muamala halisi wa Anvil haukuharibiwa; alternative external root ilitolewa kwa mkaguzi kwa njia iliyodhibitiwa ili kupima tabaka la ulinganisho.

Jaribio hili halipimi uwezekano wa kugundua shambulio wala kiwango cha usalama dhidi ya washambuliaji halisi. Lengo ni kuonyesha kwa majaribio ni tabaka gani la uadilifu linalogundua kutokulingana wakati nyuso tofauti za rekodi zinabadilishwa.

Usaidizi wa V2G-ready ni wa kweli kwa kiwango gani?

Prototipu inaweza kuchakata vipindi sintetik vya charge-only, discharge-only na bidirectional ndani ya schema ileile ya risiti. Nishati iliyoingizwa, nishati iliyosafirishwa, net energy, gharama ya import, mkopo wa export na kiasi cha net settlement ni nyuga tofauti.

Hata hivyo, utafiti haukuunganishwa na kifaa halisi cha kuchaji cha pande mbili, haukumodeli uharibifu wa betri, haukuchunguza tabia ya aggregator, haukusimulate soko la nishati na haukutekeleza huduma halisi ya grid. Kwa hiyo, kauli “V2G-ready” katika utafiti huu kimsingi inamaanisha kwamba modeli ya data na muundo wa rekodi ya settlement viko tayari kwa nishati ya pande mbili.

Maelezo ya Chanzo na Mbinu

Jina kamili asilia la utafiti: A Reproducible Blockchain-Anchored Proof-of-Charge Platform for Auditable EV Charging Receipts

Waandishi na mpangilio wao: Nexhibe Sejfuli-Ramadani; Valentina Angelkoska; Florim Idrizi; Valentin Rakovic; Erenis Ramadani; Aleksandar Risteski.

Mwandishi wa mawasiliano: Aleksandar Risteski.

Mchango sawa/mwandishi wa kwanza sawa: Haijabainishwa katika chanzo.

Taasisi:

• Faculty of Natural Sciences and Mathematics, University of Tetova, Tetovo, North Macedonia.
• Faculty of Economics, University of Skopje, Skopje, North Macedonia.
• Faculty of Electrical Engineering and Information Technologies, Ss. Cyril and Methodius University, Skopje, North Macedonia.
• Tarmac LLC, Skopje, North Macedonia.

Jarida: Future Internet

Mchapishaji: MDPI, Basel, Switzerland

Juzuu / toleo / makala: 18 / 8 / 423

Tarehe ya kupokelewa: 6 Julai 2026

Tarehe ya marekebisho: 2 Agosti 2026

Tarehe ya kukubaliwa: 8 Agosti 2026

Tarehe ya kuchapishwa: 10 Agosti 2026

DOI: 10.3390/fi18080423

Kiungo rasmi cha uchapishaji:https://doi.org/10.3390/fi18080423

Aina ya chanzo: Makala ya utafiti; prototipu ya programu iliyotekelezwa na tathmini iliyodhibitiwa ya utendaji wa kimahesabu.

Hali ya mapitio ya rika: Makala iliyochapishwa katika jarida lenye mapitio ya rika.

Leseni: Creative Commons Attribution (CC BY).

Ufadhili: Utafiti haukupokea ufadhili wa nje.

Upatikanaji wa data: Utafiti ulitumia data sintetik badala ya data halisi ya watumiaji wa kuchaji EV. Makala chanzo inaripoti kwamba msimbo, hati za kutengeneza data sintetik, mtiririko wa kazi wa majaribio, seti za data zilizoundwa, uchunguzi ghafi wa muda, vipimo vya run-level, muhtasari wa takwimu, vielelezo, vekta za majaribio ya canonicalization, membership proof, matokeo ya tamper-matrix na provenance manifest zinapatikana hadharani katika hazina ya mradi. Tarehe ya kufikia iliyotajwa katika makala ni 7 Agosti 2026.

Michango ya waandishi: Chanzo kinamtaja Nexhibe Sejfuli-Ramadani katika uundaji wa dhana na usimamizi wa mradi; Nexhibe Sejfuli-Ramadani, Erenis Ramadani na Valentin Rakovic katika metodolojia; Nexhibe Sejfuli-Ramadani na Erenis Ramadani katika programu; na Nexhibe Sejfuli-Ramadani, Erenis Ramadani, Valentina Angelkoska na Florim Idrizi katika uthibitishaji. Chanzo pia kinaeleza kwa kina, kwa kila mwandishi, uchangiaji katika uchambuzi rasmi, usimamizi wa data, uoneshaji, uandishi, usimamizi na maeneo mengine.

Mgongano wa maslahi: Chanzo kinaripoti kwamba Erenis Ramadani ameajiriwa na Tarmac LLC; waandishi wengine wameeleza kwamba hawana uhusiano wa kibiashara au kifedha unaoweza kuleta mgongano wa maslahi.

Kutokulingana kwa alama ndani ya chanzo: Ingawa katika Sehemu 4.3 nyuga za settlement zinaelezwa kama vigezo vya gharama C_import, C_export na C_net, Equation (6) kwa mwonekano hurudia vigezo vya muhtasari wa nishati E. Equation (7) inayofuata hutoa uhusiano wa gharama C_net = C_import − C_export. Tofauti hii ya alama imehifadhiwa kama ilivyo kwenye chanzo na haijasahihishwa kimya kimya.

Vikwazo vikuu vya kimetodolojia: Vipindi vya majaribio ni sintetik; mfumo hai wa OCPP/OCPI haukutumiwa. Benchmark inayorudiwa ilifanywa katika mazingira moja ya Apple M1 Max. Jaribio la blockchain lilifanywa kwenye mnyororo wa ndani wa Anvil unaotumia automatic mining. Ingawa upatanifu wa canonicalization wa Python–JavaScript ulijaribiwa, lugha zote hazikuthibitishwa. Sahihi ya kidijitali katika kiwango cha mita, uthibitishaji wa issuer certificate, trusted timestamp, mzunguko salama wa maisha wa ufunguo, privacy-preserving disclosure na upatanisho na external authoritative session registry havikutekelezwa. Uwepo wa data iliyoghushiwa au kuachwa kabla ya ahadi ya kwanza ya kuaminika hauwezi kugunduliwa kwa kujitegemea na utaratibu wa Merkle pekee.

Mbinu ya kisayansi, matokeo ya nambari, wigo wa usalama na vikwazo katika makala hii ya Verianla vinategemea utafiti uliochunguzwa. Uthibitishaji wa nje ulitumiwa tu kuthibitisha utambulisho wa uchapishaji na hali ya jarida lenye mapitio ya rika; hakuna thamani mpya ya utendaji wa majaribio, dai jipya la usalama au matokeo mapya ya blockchain kutoka vyanzo vya nje yaliyoongezwa kwenye maudhui makuu ya kisayansi.