Kapan seseorang bisa yakin bahwa transaksi L2 (Layer 2) akan disertakan dalam blok? Kapan seseorang bisa yakin bahwa pendapatan dari transaksi L2 tidak akan dibuang karena Re-org?

Artikel ini akan memperkenalkan pembaca ke seluruh proses implementasi transaksi L2 dan menganalisis kinerja keamanan di setiap tahap proses transaksi.

Prasyarat pengetahuan:

1. Seluruh proses transaksi L1 (Layer 1)

2. Penyebab dan dampak Re-orgs

3. Memahami peran dan metode operasi dalam arsitektur PBS Ethereum saat ini

4. Memahami perbedaan antara Optimistic Rollup dan Validity (ZK) Rollup

Memahami Transaksi L1

Proses Transaksi

Setelah pengguna mengeluarkan dan menandatangani transaksi, itu dikirim ke jaringan peer-to-peer dan menunggu Miner di bawah mekanisme konsensus PoW atau Pengusul di bawah mekanisme konsensus PoS untuk memasukkannya ke dalam blok. Ketika pengguna menemukan bahwa transaksi mereka telah dimasukkan dalam blok terbaru, mereka tidak dapat 100% yakin bahwa transaksi tersebut akan dicatat secara permanen dalam riwayat blockchain tersebut. Hal ini disebabkan oleh kemungkinan peristiwa blockchain yang dikenal sebagai "Re-org." Pengguna harus menunggu sampai probabilitas Re-org terjadi di blok tertentu cukup rendah untuk yakin bahwa transaksi mereka akan dicatat dalam sejarah blockchain.

Ilustrasi Proses Transaksi L1

Bahkan setelah transaksi dimasukkan ke dalam blok, Re-org mungkin tetap terjadi. Seseorang harus menunggu sampai Re-org tidak mungkin terjadi untuk yakin bahwa transaksi telah Selesai.

Probabilitas dan biaya dari Re-org bervariasi tergantung pada algoritma konsensus rantai dan nilai pasar asetnya. Metode perhitungan biaya Re-org tidak akan dibahas secara detail di sini.

Memahami Transaksi L2

Proses Transaksi

Setelah pengguna L2 menghasilkan dan menandatangani transaksi, biasanya dikirim langsung ke Sequencer yang bertanggung jawab untuk memesan transaksi. Sequencer kemudian memasukkan transaksi ini dalam blok L2. Selanjutnya, ketika Sequencer menulis data blok L2 kembali ke L1 melalui transaksi L1, pengguna dapat melihat transaksi mereka termasuk dalam blok L2 terbaru. Namun, penting untuk dicatat bahwa karena data blok L2 diunggah ke L1 melalui transaksi L1, masih ada kemungkinan menemukan L1 Re-org. Skenario ini dapat menyebabkan blok L2 tidak termasuk dalam sejarah blockchain, yang secara efektif menghasilkan L2 Re-org. Oleh karena itu, pengguna harus menunggu sampai kemungkinan L1 Re-org cukup rendah sebelum mereka dapat yakin bahwa transaksi mereka akan dicatat dalam sejarah blockchain.

Ilustrasi Proses Transaksi L2

Pengguna pertama menunggu agar transaksi mereka disertakan dalam blok L2, kemudian menunggu blok L2 diunggah ke L1 melalui transaksi L1, dan akhirnya menunggu transaksi L1 diselesaikan. Meskipun menunggu transaksi L2 disertakan dalam blok L2 oleh Sequencer menambah langkah dibandingkan dengan transaksi L1, periode menunggu ini umumnya tidak signifikan jika kapasitas blok L2 besar dan kecepatan generasi blok cepat. Sebagian besar waktu menunggu sebenarnya dihabiskan untuk mengonfirmasi transaksi L1. Dengan demikian, secara keseluruhan, pengalaman pengguna untuk transaksi L1 dan L2 mirip. Namun, apakah pengguna dapat melakukan beberapa konsesi untuk pengalaman yang lebih baik?

Pre-Konfirmasi/Konfirmasi Cepat/Konfirmasi Lembut

Pengguna idealnya harus menyaksikan transaksi L2 mereka (termasuk dalam blok L2) dimasukkan dalam blok L1, dan bahkan menunggu sampai kemungkinan Re-org cukup rendah, sebelum percaya bahwa transaksi L2 mereka telah dimasukkan. Tetapi bagaimana jika pengguna mau mempercayai Sequencer? Misalkan Sequencer dioperasikan oleh tim pengembangan L2 atau lembaga terkemuka. Jika Sequencer meyakinkan pengguna setelah menerima transaksi mereka bahwa mereka akan segera dimasukkan atau dalam blok ke-X, jaminan ini mungkin cukup bagi mereka yang bersedia mempercayai Sequencer. Ini mirip dengan pengguna yang mempercayai aplikasi dompet mereka yang tidak berulang kali memeriksa Etherscan untuk konfirmasi transaksi setelah dompet memberi tahu mereka tentang penyertaan.

Jaminan yang diberikan oleh Sequencer ini disebut sebagai Pra-Konfirmasi, Konfirmasi Cepat, atau Konfirmasi Lunak. Ini dapat dipahami sebagai jaminan inklusi transaksi "prematur" atau "lunak". Mereka tidak perlu menunggu transaksi L2 dimasukkan dalam blok L1, tetapi mereka hanyalah komitmen verbal dari Sequencer. Sequencer mungkin lupa janji mereka karena bug atau Sequencer jahat mungkin melanggar janji mereka, mengakibatkan waktu terbuang bagi pengguna atau, dalam kasus terburuk, paparan "serangan pengeluaran ganda."

Selanjutnya, kami akan memperkenalkan beberapa cara berbeda untuk menyajikan status inklusi transaksi L2.

Status Penyertaan Transaksi di Arbitrum/Optimism

Saat ini, ketika pengguna mengeksekusi transaksi di Arbitrum atau Optimism, mereka hampir segera menerima tanda terima transaksi, yang mencakup hasil dari eksekusi transaksi. Hal ini menunjukkan bahwa Sequencer sudah memesan dan mensimulasikan eksekusi transaksi secara lokal, dan tanda terima transaksi berfungsi sebagai Pra-Konfirmasi bagi pengguna.

Untuk informasi lebih lanjut mengenai siklus transaksi rinci di Arbitrum, Anda dapat merujuk ke dokumen resmi di: https://docs.arbitrum.io/tx-lifecycle

Untuk penjelasan yang lebih detail tentang siklus transaksi di Optimism, lihat dokumen resmi di: https://community.optimism.io/docs/protocol/txn-flow/#posting-to-l1

Memeriksa Status Penyertaan Transaksi di Arbitrum

Transaksi yang ditampilkan pada Arbitrum Explorer mencakup transaksi dengan Pre-Confirmation, yaitu transaksi yang belum diunggah ke L1. Seperti yang ditunjukkan dalam gambar berikut, transaksi dengan Nomor Blok 145353000 ditandai sebagai “Dikonfirmasi oleh Sequencer,” menunjukkan bahwa transaksi tersebut telah dikonfirmasi oleh Sequencer tetapi belum diunggah ke L1:

[Gambar menunjukkan transaksi dikonfirmasi oleh Sequencer tetapi belum diunggah ke L1]

Sebaliknya, gambar berikutnya menunjukkan transaksi yang telah diunggah ke L1, dengan status "69 L1 Block Confirmations." Ini berarti bahwa blok L1 yang berisi data transaksi ini memiliki 69 blok yang mengikutinya, yang menunjukkan tingkat keamanan yang lebih tinggi:

[Gambar menunjukkan transaksi di L1 dengan 69 konfirmasi blok]

Contoh lainnya adalah transaksi dengan 6174 konfirmasi blok L1, seperti yang ditunjukkan di bawah ini, yang dianggap sangat aman.

Namun, akan lebih baik jika informasi Finalitas L1 diintegrasikan ke dalam tampilan ini. Hanya memberi tahu pengguna jumlah Konfirmasi Blok L1 memiliki bantuan terbatas, karena mereka harus memahami dan menghitung tingkat keamanan yang diwakili oleh angka ini. Karena Layer 1 (Ethereum) memiliki mekanisme Finalitas seperti Casper FFG, Penjelajah dapat langsung menampilkan apakah blok Layer 1 telah Difinalisasi. Saat ini, Penjelajah Optimisme telah mengimplementasikan fitur ini.

Memeriksa Status Pengikutsertaan Transaksi di Optimism

Transaksi yang ditampilkan di Optimism Explorer juga mencakup yang dengan Pra-Konfirmasi, yaitu transaksi yang belum diunggah ke L1. Seperti yang ditunjukkan dalam gambar berikut, transaksi dengan Nomor Blok 111526300 ditandai sebagai “Dikonfirmasi oleh Sequencer”:

[Gambar menunjukkan transaksi hanya dikonfirmasi oleh Sequencer tetapi tidak diunggah ke L1]

Namun, Explorer tidak secara jelas mendefinisikan arti dari "Dikonfirmasi oleh Sequencer." Ia menyatakan, "Konfirmasi Sequencer setara dengan beberapa konfirmasi blok di L1," menyarankan bahwa transaksi yang ditandai sebagai "Dikonfirmasi oleh Sequencer" telah diunggah ke L1 dan memiliki beberapa blok yang mengikuti itu:

[Gambar menunjukkan transaksi terbaru yang ditandai sebagai “Dikonfirmasi oleh Sequencer”]

Transaksi dari beberapa hari yang lalu, bahkan yang sudah melewati periode tantangan, masih menampilkan status "Dikonfirmasi oleh Penyusun Urutan":

[Gambar menunjukkan transaksi dari hari yang lalu masih ditandai sebagai "Dikonfirmasi oleh Sequencer"]

Catatan: Explorer mungkin menampilkan status yang berbeda di tempat yang berbeda: "Dikonfirmasi Oleh Sequencer" di sebelah Nomor Blok menunjukkan bahwa blok telah dikonfirmasi oleh Sequencer. Untuk memeriksa status setelah diunggah ke L1, pengguna perlu mencari informasi lain, seperti "L1 State Batch" yang disebutkan di bawah ini.

Seperti yang ditunjukkan dalam tangkapan layar berikut, transaksi yang sudah diunggah ke L1 mencakup informasi tambahan: "Indeks Batch Status L1" dan "Hash Transaksi Pengiriman Akar Status L1." Detail-detail ini menunjukkan transaksi Status L2 termasuk dalam Batch Status L1 mana dan transaksi L1 mana yang mengunggah Batch Status ini ke L1:

[Gambar menunjukkan transaksi dengan informasi Batch State L1]

Mengklik Batch Negara “3480” mengungkapkan statusnya sebagai Finalized. Status Finalized ini sesuai dengan mainnet Ethereum dan menunjukkan keadaan yang sangat aman, setelah berhasil mengumpulkan dua epoch suara validator.

[Gambar menunjukkan Batch Negara 3480 finalisasi di Blok L1 18457449]

Sumber: https://etherscan.io/block/18457449

Jika suatu Batch telah diunggah tetapi belum Finalized di L1, maka akan ditampilkan sebagai Unfinalized:

[Gambar menunjukkan satu Batch Negara diunggah ke L1 tapi belum difinalisasi]

Dibandingkan dengan Arbitrum Explorer, Optimism Explorer menyediakan lebih banyak informasi (State Batch) dan langsung mengintegrasikan informasi Finality L1 ke dalam L2 Explorer, sehingga pengguna dapat mengetahui apakah blok L1 telah Difinalisasi tanpa harus menafsirkan jumlah Konfirmasi Blok untuk keamanan.

Status Pendapatan Transaksi StarkNet

Saat ini, ketika pengguna mengirim transaksi di StarkNet, mereka dapat dengan cepat mengakses tanda terima transaksi. Namun, status yang sering ditampilkan pada tanda terima adalah DITERIMA, yang menunjukkan bahwa node telah menerima dan memvalidasi transaksi tanpa kesalahan. Kemudian, transaksi akan menunggu inklusi dan eksekusi dalam blok L2 oleh Sequencer. Transaksi dengan status DITERIMA belum memiliki hasil eksekusi. Pengguna dapat memantau kemajuan transaksi mereka melalui status yang ditampilkan di StarkNet Explorer.

Catatan: Jika Sequencer memproses transaksi dengan cukup cepat, mungkin akan melewati status DITERIMA dan langsung beralih ke status diproses. Untuk pengenalan yang lebih detail tentang proses transaksi StarkNet, lihat dokumen resmi di https://docs.starknet.io/documentation/architecture_and_concepts/Network_Architecture/transaction-life-cycle/

Di Starkscan, sebuah StarkNet Explorer, transaksi termasuk Pre-Confirmation ditampilkan. Misalnya, transaksi yang ditunjukkan sebagai "Diterima di L2" menunjukkan bahwa transaksi tersebut telah diurutkan ke dalam blok L2:

“Diterima di L2” berarti transaksi telah dimasukkan ke dalam blok L2 tetapi belum diunggah ke L1.

Kedua status sebelumnya, Diterima dan Tertunda, mewakili "transaksi diterima dan divalidasi" dan "transaksi sedang diproses oleh Sequencer." Setelah diproses, status berubah menjadi Diterima di L2.

Transaksi diterima dan diverifikasi

Transaksi sedang diproses oleh Sequencer

Setelah data transaksi diunggah ke L1, status akan berubah menjadi Diterima di L1, seperti yang ditunjukkan pada gambar di bawah ini untuk transaksi ini:

Data transaksi telah diunggah ke L1

Meskipun transaksi StarkNet memiliki kumpulan status yang lebih kaya, memungkinkan pengguna untuk mengetahui kemajuan transaksi mereka, mengunggah ke L1 bisa memakan waktu beberapa jam, terutama karena waktu yang diperlukan untuk menghasilkan bukti pengetahuan nol. Oleh karena itu, pengguna mengandalkan Pre-Konfirmasi Sequencer selama periode ini.

StarkNet Explorer hanya menampilkan status Diterima pada L1 tanpa menyertakan informasi tentang Finalitas L1 atau Konfirmasi Blok. Pengguna perlu memeriksa apakah cukup blok telah ditambahkan setelah transaksi mereka di L1 atau apakah telah Finalized.

Karena keterbatasan kinerja StarkNet, ketergantungan yang lama pada Pre-Confirmation, dan kurangnya dukungan untuk informasi L1 Finality di Explorer, pengalaman pengguna untuk konfirmasi inklusi transaksi di StarkNet perlu ditingkatkan.

Status Inklusi Transaksi zkSync

Sama seperti StarkNet, zkSync juga memiliki status TERTUNDA, yang menunjukkan bahwa node telah menerima dan memverifikasi transaksi tanpa masalah. Transaksi kemudian akan menunggu untuk disertakan dan dieksekusi dalam blok L2 oleh Sequencer. Transaksi dalam status TERTUNDA belum memiliki hasil eksekusi apa pun.

Pengguna dapat melacak kemajuan transaksi mereka melalui status yang ditampilkan di zkSync Explorer.

Petunjuk Membaca: Jika Sequencer memproses transaksi dengan cukup cepat, mungkin akan melewati status TERTUNDA dan langsung beralih ke keadaan di mana transaksi sudah diproses.

Untuk pengenalan lebih rinci tentang proses transaksi zkSync, ikuti tautan ini: https://era.zksync.io/docs/reference/concepts/finality.html#finality-on-ethereum

Transaksi yang dilihat di Penjelajah zkSync juga termasuk transaksi Pra-Konfirmasi, seperti yang ada di tangkapan layar di bawah ini. Status saat ini adalah “Diproses Era zkSync,” menunjukkan bahwa transaksi tersebut telah diatur ke dalam blok L2 oleh Sequencer:

Transaksi telah disusun ke dalam blok L2 oleh Pengurut dan saat ini menunggu untuk diunggah ke L1 (Pengiriman Ethereum).

Setelah Sequencer menyelesaikan blok L2, blok dan transaksinya melewati tiga tahap: Dikonfirmasi, Terbukti, dan Dijalankan. Ini masing-masing menunjukkan “blok diunggah ke L1,” “keabsahan blok terbukti,” dan “keadaan L2 setelah eksekusi transaksi dalam blok diperbarui ke L1.” Berikut contoh blok dan transaksi dalam tahap-tahap berbeda ini:

Batch 292700 telah diunggah ke L1 dan masuk ke tahap Terikat. Sumber: https://explorer.zksync.io/batch/292700

Status transaksi dalam Batch 292700 berubah dari Pengiriman Ethereum menjadi Validasi Ethereum, menunjukkan bahwa mereka menunggu validasi bukti nol pengetahuan atas keabsahan mereka.

Menggerakkan panah di atas ikon Ethereum Validating juga akan menampilkan tahapan-tahapan yang berbeda, dan tautan transaksi untuk tahap sebelumnya (Mengirim) juga akan dilampirkan:

Transaksi ini telah memasuki tahap “Validating”. Tautan transaksi untuk mengunggah Batch ke L1 di tahap sebelumnya (Mengirim) juga dapat dilihat langsung di sini.

Batch 292000 telah terbukti valid, sehingga masuk ke tahap Terbukti:

Setelah suatu batch terbukti, masuk ke dalam status Terbukti, dengan tautan ke transaksi yang menjalankan tindakan Membuktikan.

Transaksi kemudian berpindah dari status “Validating” ke “Executing,” yang berarti mereka sedang menunggu untuk dieksekusi.

Setelah Batch terbukti, ada periode penundaan (sekitar 21 jam menurut dokumentasi resmi) sebelum menjalankan transaksi di dalamnya dan memperbarui status L2 yang tercatat di L1. Ini adalah langkah perlindungan dalam fase Alpha untuk memastikan waktu reaksi yang cukup dalam kasus bug. Setelah Batch dijalankan, masuk ke tahap Eksekusi akhir:

Setelah dieksekusi, Batch memasuki keadaan Terkirim akhir, dengan tautan ke transaksi yang mengeksekusi tindakan Eksekusi.

Status transaksi dalam Batch juga diperbarui menjadi “Dieksekusi.”

Dibandingkan dengan StarkNet, di mana transaksi bergerak dari L2 ke L1 dalam satu langkah, zkSync memecah proses dari L2 ke L1 menjadi tiga tahap yang lebih terperinci: Terkomitmen → Terbukti → Dieksekusi. Meskipun sebagai langkah perlindungan, seluruh proses transaksi memakan waktu sekitar satu hari, status Terkomitmen memungkinkan pengguna untuk dengan cepat mengetahui apakah transaksi mereka telah disertakan (setelah Terkomitmen, bukan hanya Pra-Konfirmasi) tanpa hanya mengandalkan kepercayaan pada Sequencer. Selain itu, zkSync Explorer menyediakan data komprehensif untuk setiap tahap, memungkinkan siapa pun untuk melacak status terbaru transaksi dan bahkan memverifikasi transisi antara tahap (misalnya, dari Terkomitmen ke Terbukti, dari Terbukti ke Dieksekusi).

Namun, penting untuk dicatat bahwa sebagai langkah perlindungan dalam fase Alpha, Sequencer zkSync saat ini dapat memodifikasi catatan historis. Ini berarti bahwa meskipun transaksi dapat segera pindah dari Pra-Konfirmasi ke tahap Terikat, Sequencer masih dapat menghapus transaksi pengguna dari catatan historis hingga mencapai tahap Dieksekusi. Oleh karena itu, pengguna masih perlu mempercayai Sequencer hingga satu hari.

L1 juga dapat mendukung pra-konfirmasi

Jika memungkinkan untuk mengetahui sebelumnya siapa yang bertanggung jawab untuk memproduksi blok, maka L1 juga dapat mendukung Pra-Konfirmasi. Mengambil contoh Ethereum, produsen blok sebenarnya adalah Builder, yang dapat menawarkan layanan Pra-Konfirmasi, memberikan jaminan kepada pengguna terkait inklusi transaksi. Namun, karena Builder tidak memiliki hak yang dijamin untuk memproduksi blok tertentu tetapi harus menawar hak untuk memproduksi setiap blok, maka efektivitas Pra-Konfirmasi ini relatif lemah. Selain itu, kekuatan dari Builder juga harus dipertimbangkan; jika seorang Builder kurang memiliki kekuatan bersaing, maka akan sulit baginya untuk memenangkan hak untuk memproduksi blok, yang mengurangi nilai layanan Pra-Konfirmasinya.

Solusi yang lebih baik untuk menghindari masalah-masalah ini adalah bagi Penyaji untuk menawarkan layanan Pra-Konfirmasi, karena biasanya sudah ditentukan dan pasti Penyaji mana yang akan mengajukan blok mana. Namun, dalam arsitektur PBS (Pemisahan Penyaji-Pembangun) saat ini, Penyaji hanya bertanggung jawab untuk mengusulkan blok, sementara Pembangun yang memutuskan konten blok tersebut. Oleh karena itu, Penyaji tidak dapat langsung memasukkan transaksi ke dalam blok atau meminta Pembangun untuk melakukannya. Situasi ini mungkin berubah dengan modifikasi masa depan terhadap arsitektur PBS, seperti menambahkan Daftar Penyertaan atau memungkinkan Penyaji untuk berpartisipasi dalam produksi blok, memungkinkan Penyaji untuk menawarkan layanan Pra-Konfirmasi.

Tips membaca: Untuk informasi lebih lanjut tentang PBS, silakan salin tautan di bawah ini ke browser Anda untuk membaca: https://mirror.xyz/0x347c9872A2a1dE370D798f9FE96341A9A0E05af8/oG_4j_-TweXHX_LMag656k_pAyJWIBXpEDrzpUfVsss.

Meningkatkan Pra-Konfirmasi

Pre-Konfirmasi hanyalah janji lisan dari Seorang Builder atau L2 Sequencer, tanpa kewajiban untuk memenuhinya dan tanpa mekanisme hukuman atas pelanggaran. Bisakah janji ini menjadi lebih dapat diandalkan? Ya, karena konten dari komitmen (misalnya, "masukkan transaksi ini ke dalam blok 1350000") yang dibuat oleh orang yang bertanggung jawab atas produksi blok dapat ditulis sebagai pemeriksaan bersyarat. Dengan demikian, kita dapat menggunakan kontrak pintar untuk mengatur Builder atau Sequencer, meminta mereka untuk mendepositkan jaminan dalam kontrak pintar ketika menawarkan layanan Pre-Konfirmasi dan untuk menandatangani konten komitmen. Jika pengguna menemukan bahwa Builder atau Sequencer tidak memenuhi janji mereka, mereka dapat mengirimkan komitmen dan tanda tangan ke kontrak pintar untuk diverifikasi.

Meskipun penerapan kontrak semacam itu masih dalam tahap proof-of-concept, tautan berikut ke video presentasi menampilkan satu contoh penerapan kontrak:

https://www.youtube.com/watch?v=Uw5HxSYXwYo

Ringkasan

Setelah transaksi L1 dimasukkan ke dalam blok L1, probabilitas Re-org secara bertahap menurun, dan kepercayaan pengguna terhadap transaksi mereka yang dimasukkan meningkat.

Transaksi L2 memiliki alur kerja tambahan dibandingkan dengan transaksi L1: fase "transaksi L2 disertakan dalam blok L2 dan menunggu diunggah ke L1." Selama fase ini, karena data belum diunggah ke L1, masih ada kemungkinan perubahan, dan satu-satunya jaminan pengguna tentang inklusi transaksi mereka adalah komitmen lisan dari Sequencer, yang dikenal sebagai Pra-Konfirmasi, Konfirmasi Cepat, atau Konfirmasi Lunak.

Jika Sequencer bersifat jahat atau mengalami bug, komitmen mereka mungkin akan terganggu, yang berpotensi menyebabkan kurangnya konfirmasi untuk transaksi L2 pengguna.

Saat ini, sebagian besar L2 menampilkan status transaksi di Explorer mereka, termasuk status Pra-Konfirmasi, seperti “Dikonfirmasi oleh Sequencer” dari Arbitrum/Optimism atau “Diterima di L2” dari StarkNet. Pengguna harus menyadari validitas waktu jaminan inklusi transaksi yang diberikan oleh status-status ini.

Jika pengguna tidak ingin mempercayai Pre-Konfirmasi Sequencer, mereka harus menunggu lebih lama dan memvalidasi melalui informasi yang diberikan oleh L2 Explorer tentang data L2 yang diunggah ke L1.

Pre-Konfirmasi dapat mencakup mekanisme insentif ekonomi, seperti denda melalui kontrak pintar bagi Sequencer yang melanggar janjinya, menawarkan perlindungan yang lebih jelas kepada pengguna.

Tabel di bawah ini menunjukkan jaminan inklusi transaksi dan skenario risiko yang sesuai untuk berbagai tahap transaksi L1 dan L2: [Harap dicatat bahwa tabel tidak disediakan dalam terjemahan.]

Penyangkalan：

1. Artikel ini dicetak ulang dari [imToken Labs]. Semua hak cipta milik penulis asli [Nic]. Jika ada keberatan terhadap pencetakan ulang ini, harap hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penyangkalan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.