Ini jelas bertentangan dengan model pengembangan game tradisional. Game tradisional yang sukses menarik banyak pengguna melalui mekanika permainan yang menarik, memungkinkan pengembang membangun jalur yang menguntungkan dan berpotensi berkembang ke produk-produk terkait dan IP. Game-game ini beroperasi dalam siklus positif di mana pemain menikmati permainan dan sering mendapatkan manfaat ekonomi baik di dalam maupun di luar game.

Sebaliknya, permainan blockchain saat ini terutama menarik pemain melalui pengembalian keuangan. Selain rendahnya daya tarik bermain, permainan Web3 juga menghadapi masalah yang telah lama seperti hambatan masuk yang tinggi dan proses interaksi yang rumit.

Apa akar penyebab dari masalah-masalah ini? Pendapat bervariasi. Tim TabiChain percaya faktor signifikan adalah bahwa pengembang game tradisional berbakat kesulitan masuk ke ekosistem Web3 karena hambatan teknis dan pembelajaran. Bagi yang tidak familiar dengan pengembangan game atau perangkat lunak, beralih dari Web2 ke Web3 mungkin terlihat seperti hanya perubahan naratif dan lingkungan, tetapi kenyataannya jauh lebih keras.

Jadi, bagaimana kita bisa menciptakan lingkungan yang lebih ramah bagi pengembang game tradisional atau perusahaan terkait melalui teknologi? Pada bagian-bagian berikut, kita akan menganalisis secara menyeluruh tantangan yang dihadapi oleh game Web3 dan solusi-solusinya, menjelaskan bagaimana industri game Web3 masa depan dapat disesuaikan secara teknis untuk lebih cocok bagi pengembang game tradisional.

Alasan Teknis yang Menghambat Pengembang Game Tradisional Masuk ke Ekosistem Web3

Pada artikel sebelumnya, kami sempat menyebutkan bahwa teknologi yang tidak ramah dan biaya pembelajaran yang tinggi adalah faktor inti yang mencegah praktisi game tradisional memasuki ekosistem web3. Teknologi yang tidak ramah dan biaya pembelajaran yang tinggi yang disebutkan dapat diperluas menjadi beberapa hal berikut:

1. Perbedaan antara aplikasi web3 dan struktur perangkat lunak tradisional

Blockchain dan aplikasi di atasnya (dApps) secara fundamental berbeda dari arsitektur perangkat lunak tradisional dan memerlukan pengembang untuk memiliki sistem pengetahuan baru, seperti prinsip kerja blockchain, protokol konsensus, model pemrograman kontrak pintar, dll. Pengembang game tradisional perlu menghabiskan banyak waktu untuk mempelajari Solidity atau bahasa kontrak pintar lainnya dan perlu memahami bagaimana EVM bekerja.

Selain itu, logika permainan tradisional biasanya dijalankan pada server terpusat, yang dapat menangani fleksibel keadaan permainan yang kompleks dan interaksi berfrekuensi tinggi. Menjalankan logika permainan pada blockchain memerlukan tingkat penyederhanaan atau perbaikan yang tinggi, karena setiap operasi harus dipublikasikan ke jaringan terdistribusi untuk dieksekusi dan kemudian diunggah ke rantai, yang sangat dibatasi oleh kinerja dan biaya dari blockchain.

1. Batasan desain dari kontrak pintar

Meskipun EVM adalah lengkap Turing dan pada teori dapat mengekspresikan logika sembrono, karakteristiknya sangat tidak menguntungkan untuk pengembangan game, seperti:

• Kekurangan timer. Semua operasi pada rantai Ethereum harus dipicu secara manual oleh akun EOA. Untuk mencapai efek yang mirip dengan timer, pengembang perlu mendeploy layanan tambahan dan memelihara akun EOA dan daftar acara untuk memicu tugas-tugas terjadwal secara manual. Karena masalah keterlambatan pada rantai, tugas-tugas terjadwal ini tidak dapat dijamin selesai tepat waktu.

• Tidak ada panggilan kembali dan mekanisme lainnya, dan tidak mendukung multi-threading dan asynchronous. Karena Solidity dirancang untuk pengembangan kontrak pintar Ethereum, lingkungan eksekusinya jauh berbeda dari lingkungan runtime tradisional. Operasi EVM bersifat transaksional, dan setiap panggilan fungsi perlu dieksekusi sepenuhnya dalam sebuah transaksi. Tidak ada konsep “asynchronous” dalam arti tradisional. Ini berarti bahwa panggilan fungsi di Solidity bersifat atomik dari awal hingga akhir dan tidak dapat diinterupsi oleh transaksi lainnya.
• Tidak ada kemampuan untuk merujuk data eksternal. Meskipun ada orakel seperti Chainlink, baik dari perspektif integrasi maupun perspektif panggilan data, kemudahannya jauh berbeda dari langsung mendapatkan panggilan data melalui permintaan https, dan ini memungkinkan pengembang untuk menambahkan integrasi tambahan. Beban dan ketergantungan.
• Keterbatasan skalabilitas dan kinerja. Logika permainan harus disederhanakan atau dibagi menjadi beberapa transaksi sederhana untuk menghindari biaya gas dari satu transaksi menjadi terlalu tinggi atau melebihi batas maksimum, yang membatasi implementasi interaksi dan fungsi kompleks.

1. Batasan penyimpanan dan pengambilan data

• Kontrak pintar memiliki ruang penyimpanan yang mahal dan desain terbatas, sehingga membuatnya tidak cocok untuk menyimpan jumlah data game yang besar.
• Log acara mungkin diperlukan untuk secara tidak langsung melacak status permainan, dan penangkapan acara mungkin tidak stabil. Masalah seperti kapan harus menyegarkan status permainan sering kali memerlukan pemain atau operator permainan untuk memicunya secara manual.
• Struktur data akun yang diadopsi oleh EVM mengakibatkan kemampuan indeks data yang buruk. Ketika Anda mengajukan pertanyaan mengenai data suatu akun, Anda hanya dapat mengetahui saldo ETH atau token berbasis rantai-nya, tetapi aset ERC-20 apa yang dimilikinya dan saldo dari setiap aset tidak dapat diketahui secara langsung. Hal yang sama berlaku untuk NFT. Informasi ini terenkapsulasi dalam kontrak eksklusif dari setiap aset, bukan disimpan di bawah akun pengguna sendiri.

Kita dapat melihat jenis token dan informasi saldo apa yang dimiliki alamat tertentu dari alat seperti Etherscan. Ini diindeks oleh alat periferal seperti browser blockchain, dan yang terakhir perlu membangun database besar khusus dan merayapinya sepenuhnya. Hanya dengan mengumpulkan semua data blok atau memantau peristiwa pada rantai, semua data pada rantai dapat diringkas.

Pengembang Web3 biasanya harus mengintegrasikan penyedia data pihak ketiga seperti Etherscan, NFTscan, The Graph, dll., dan bahkan membayar untuk API KEY mereka. Selain itu, layanan pihak ketiga ini pada dasarnya adalah basis data off-chain, yang dapat menyebabkan keterlambatan, kesalahan, melebihi batas panggilan, layanan tidak tersedia, dan kegagalan lainnya.

Mari kita bandingkan perbedaan antara bentuk database dari kebanyakan permainan dan metode penyimpanan data di blockchain. Perbedaan antara keduanya jelas. Struktur data dari kebanyakan permainan sepenuhnya disesuaikan oleh dirinya sendiri, memiliki kemampuan ekspresi dan indeksasi yang baik, dan tidak perlu mengandalkan layanan pihak ketiga apa pun.

1. Tantangan dalam mengintegrasikan aset game yang sudah ada dengan blockchain

Aset game yang sudah ada (seperti properti dan karakter) biasanya tidak diciptakan dan dikelola di blockchain. Memindahkan aset-aset ini ke blockchain biasanya melibatkan mengonversi tipe data umum tetapi long-tail menjadi NFT atau Token standar, yang melibatkan pekerjaan migrasi dan integrasi yang kompleks dan akan memengaruhi sistem ekonomi game yang sudah ada.

1. Peningkatan, perbaikan, dan pencegahan bencana

Di Ethereum, begitu kontrak pintar dideploy, kode tersebut bersifat tak dapat diubah, membuat peningkatan dan perbaikan lebih kompleks dibandingkan dengan perangkat lunak tradisional. Pengembang sering menggunakan kontrak proksi atau pola versi untuk menghindari batasan ini, namun hal ini meningkatkan kompleksitas struktur keseluruhan. Kontrak proksi perlu digunakan dengan hati-hati khusus untuk menghindari korupsi data yang disebabkan oleh konflik slot penyimpanan. Selain itu, risiko kebocoran hak administratif juga serius.

Peningkatan kode permainan tradisional tidak terlalu rumit dalam hal struktur teknis. Satu-satunya hal yang mungkin perlu dibatasi adalah otoritas upgrade terpusat. Ini dapat dicapai melalui metode seperti DAO daripada bergantung pada kontrak pintar.

Selain itu, permainan tradisional sering kali mengambil snapshot atau cadangan database. Hal ini mungkin tidak terlalu penting biasanya, tetapi jika Anda mengalami bug besar dalam upgrade, Anda dapat dengan cepat mengembalikan data tersebut, yang pada dasarnya adalah hal yang mustahil dalam blockchain. Bahkan jika beberapa data permainan dikembalikan dengan membangun kembali kontrak, cara melakukan migrasi data dan status kontrak lama ke kontrak baru masih merupakan hal yang rumit.

1. Fragmentasi ekologis dan masalah pengalaman pengguna

Berbagai rantai publik dan VM memiliki bahasa kontrak pintar, arsitektur, struktur data, dsb. yang benar-benar berbeda. Di Web2, pengembang game akan memilih mesin depan lintas platform seperti Unity, yang dapat membuat seperangkat kode sedikit disesuaikan untuk berjalan di lingkungan yang berbeda seperti iPhone, Android, dan desktop. Karena back-end tidak berjalan di terminal pengguna, tidak ada masalah lintas platform.

Di Web3, ini pada dasarnya merupakan kemewahan. Migrasi ke rantai atau VM yang berbeda berarti merekonstruksi seluruh proyek dan menimbulkan biaya besar. Lebih dari itu, pengembang yang baru mengenal Web3 sama sekali tidak memiliki pengalaman untuk memilih ekosistem yang cocok bagi mereka. Apakah ini dari perspektif teknis atau perspektif ekologis?

Pada tingkat pengalaman pengguna, interaksi blockchain sangat kompleks. Konsep abstraksi akun yang begitu populer sebelumnya muncul tepat untuk memecahkan masalah pengalaman pengguna web3, jadi saya tidak akan membahas detail di sini.

Setelah mencantumkan 6 argumen utama di atas, mari kita ringkas: pengembang dari web2 ke web3 menghadapi ambang batas adaptasi yang besar. Jika mereka adalah pengembang teratas di web2, tidak perlu meninggalkan karier mereka di web2 dan beralih ke lingkungan asing seperti web3. Di lingkungan ini, kami mengembangkan beberapa bisnis yang tidak kita tahu apakah mereka bisa sukses atau tidak.

Bisa dikatakan, Sebagian besar pengembang game teratas belum memasuki Web3. Sampai batas tertentu, hal ini membuat sebagian besar game Web3 cenderung pada spekulasi keuangan daripada memiliki tingkat daya main dan kesenangan yang sangat tinggi.

Hambatan yang sama juga ada di sisi pengguna. Permainan Web3 memiliki serangkaian langkah operasi yang menghambat tingkat konversi pengguna, mengakibatkan kelompok pengguna besar dari Web2 yang tidak bersedia mengalami atau bahkan sama sekali tidak sadar akan keberadaan permainan Web3.

Apakah ada proyek tingkat infrastruktur yang dapat menyelesaikan masalah di atas? Tabi Chain mungkin menjadi proyek yang sangat dekat dengan salah satu solusi utama untuk permainan Web3. Konsep intinya adalah “Omni Execution Layer”: Pengembang tidak perlu lagi peduli dengan perbedaan antara berbagai VM atau lingkungan operasional. Mereka dapat langsung menggunakan lingkungan operasional yang akrab atau bahkan dapat disesuaikan untuk langsung mengembangkan atau mengimpor permainan.

Selain itu, Tabi Chain juga memiliki konsensus modular, lapisan keamanan, dan fitur lainnya. Semuanya modular dan dapat disesuaikan untuk memenuhi kebutuhan permainan dan aplikasi yang berbeda.

Lapisan Eksekusi Omni: Memilih Lingkungan Eksekusi Berdasarkan Kebutuhan Pengembang

Mari kita ulang konsep dasar blockchain. Meskipun beberapa orang mungkin menggambarkannya sebagai buku besar terdesentralisasi yang tidak dapat diubah, sebenarnya lebih tepat didefinisikan sebagai sinkronisasi yang dapat diverifikasi dari status permanen mesin keadaan dalam jaringan terdistribusi.

Pada intinya, blockchain menjaga mesin status yang diterima secara universal dan status operasionalnya:

• Setiap input adalah deterministik, tercatat di setiap blok;
• Fungsi transisi negara adalah deterministik, diwakili oleh VM atau runtime dalam klien blockchain;
• Negara output juga bersifat deterministik, tercatat di setiap blok;

Oleh karena itu, sistem konsensus blockchain tidak perlu terbatas pada satu lapisan eksekusi (seperti hanya EVM). Terlepas dari jumlah lapisan eksekusi, selama rantai dapat memverifikasi keadaan di berbagai lapisan, memungkinkan setiap permainan untuk beroperasi di lingkungannya sendiri, kita dapat menangani berbagai isu yang telah dibahas sebelumnya.

Di Tabi, setiap permainan atau dApp dapat membangun Layanan independen mereka sendiri. Semua Layanan mengirimkan blok yang dihasilkan sendiri ke sistem konsensus rantai; Node Supervisor termasuk runtime/VM di semua Layanan untuk memverifikasi status blok layanan. Inti lapisan eksekusi Tabi yang menyeluruh dapat dianggap sebagai VM dengan kemampuan polimorfik, sehingga disebut Polimorfisme VM.

Untuk VM blockchain yang ada, sebuah VM Polimorfisme perlu mengintegrasikan VM ini dalam lingkungan runtime-nya dan menyediakan metode pemanggilan antarmuka yang diperlukan. Konsep “integrasi” di sini dapat diimplementasikan dalam dua cara:

Status Dunia Bersama: Mirip dengan Ethermint, yang mendukung EVM pada Cosmos. EVM berperan sebagai lapisan permukaan, berfokus pada interaksi pengguna dan operasi kontrak, sehingga semua aktivitas sisi pengguna tampaknya dieksekusi pada EVM. Namun, hasil akhir dan data dari operasi-operasi ini disimpan di modul-modul Cosmos lainnya. Dengan demikian, kompatibilitas EVM ini pada dasarnya adalah pemetaan data yang mendasarinya.

Hubungan pemetaan ini dapat diperluas ke VM lain juga. Sebagai contoh, Ethermint dapat menyertakan lapisan modul SVM tambahan, di mana baik SVM maupun EVM sesuai dengan data dasar yang sama.

Ini mirip dengan menggunakan VMWare pada PC untuk menjalankan mesin virtual Windows. VMWare dapat mengakses baik hard drive virtual mesin virtual maupun hard drive komputer fisik. Jika Anda kemudian memulai mesin virtual Mac, ia dapat melakukan mounting data dari disk fisik dengan cara yang sama. Penyiapan ini efektif memungkinkan beberapa mesin virtual untuk berbagi sumber daya dan status dari lingkungan yang sama.

Layanan Utama Tabi Chain akan menggunakan pendekatan status dunia bersama. Ini berarti bahwa selama VM yang sesuai diadaptasi, dApps yang dikembangkan untuk VM tersebut dapat diterapkan langsung pada Layanan Utama tanpa perlu membuat layanan terpisah.

Negara Dunia Independen: Berbagai aplikasi dan game memiliki kebutuhan yang unik, dan beberapa game menggunakan runtime kustom. Oleh karena itu, pendekatan universal untuk mengintegrasikan semua VM melalui "negara dunia bersama" dalam VM Polimorfisme tidak cocok untuk setiap kasus. Sebuah negara dunia independen juga diperlukan, karena lebih sederhana untuk diimplementasikan dan ideal untuk layanan dengan data yang benar-benar terpisah.

Terlepas dari pendekatan yang digunakan, harus dapat diverifikasi oleh Supervisor Nodes. Ini berarti bahwa Polymorphism VM harus mencakup semua VM atau runtime yang digunakan oleh berbagai metode implementasi.

Contoh Porting Game Web2

VM Polymorphism sangat dapat disesuaikan, membuatnya sangat bermanfaat bagi pengembang Web2. Mereka dapat menggunakan bahasa dan kerangka kerja yang akrab untuk memindahkan logika bisnis apa pun ke VM Polymorphism.

Anggaplah Minecraft ingin dipindahkan ke Tabi. Proses umumnya akan sebagai berikut:

1. Ubah Kode Server: Sedikit modifikasi kode server Minecraft (Java atau bahasa lainnya), memindahkan data yang perlu ada di rantai ke database (atau seperangkat database). Identifikasi dan pilih semua fungsi yang mungkin mengubah database ini (yaitu, fungsi transisi status).
2. Kemas Komponen-Komponen Ini: Kemas basis data dan fungsi-fungsi ini ke dalam file JAR, yang merupakan program eksekusi dalam Java. Sertakan JRE (Java Runtime Environment) dalam paket ini. Seluruh paket ini kemudian dimuat ke dalam Polymorphism VM, memastikan semua data ada di rantai.
3. Jalankan Logika Off-Chain: Jalankan logika backend lainnya yang tidak perlu berada di rantai (seperti pembentukan tim, obrolan, dll.) pada server off-chain.
4. Memulai Layanan: Memulai Layanan di Tabi Chain dan memberitahukan Polymorphism VM Node Supervisor untuk memuat JRE yang sama.
   

Dengan ini, seluruh proses sudah selesai.

Bagi para pengembang, modifikasi ini dilakukan dalam bahasa dan kerangka kerja Java yang sudah ada. Konsep yang sama berlaku untuk game yang dikembangkan menggunakan metode lain. Bagi pengguna, interaksi game tetap sama. Jelas, metode porting game Web2 ini sangat cepat dan efisien, berpotensi menjadi model dasar untuk adopsi massal game Web3.

Detail dari Fungsi Game STR (State Transition Runtime)

Contoh sebelumnya memberikan gambaran umum tentang memporting game Web2. Untuk memperoleh pemahaman yang lebih dalam, kita perlu menyelami lebih detail. Kali ini, kita akan menggunakan contoh umum daripada game spesifik untuk mengilustrasikan detail yang terlibat dalam runtime Omni-Execution Layer.

Pada dasarnya, menyesuaikan lingkungan runtime permainan dapat dianggap sebagai menciptakan mesin keadaan permainan di blockchain, yang disebut sebagai Runtime Transisi Status (STR) di Tabi.

Contoh di atas adalah proses umum dari porting permainan Web2. Kita masih perlu tahu lebih banyak tentang detailnya. Kali ini kita menggunakan contoh umum daripada contoh permainan tertentu untuk menunjukkan detail yang terlibat dalam runtime di lapisan eksekusi yang mahakuasa.

Pada dasarnya, menyesuaikan lingkungan berjalan permainan dapat dianggap sebagai menciptakan mesin keadaan untuk permainan tertentu pada blockchain, yang disebut Runtime Transisi Keadaan di Tabi.

STR dapat diintegrasikan ke Polymorphism VM dalam bentuk biner atau modul.

Dalam sistem seperti blockchain, kita perlu memastikan transparansi input, visibilitas publik dari transisi negara, dan ekspresi negara global. Untuk memenuhi persyaratan ini, kita perlu membangun runtime dengan fitur-fitur berikut:

1. World DBBerisi semua data pengguna dalam aplikasi yang perlu direkam di blockchain. Data ini seharusnya berharga dan penting, sehingga diperlukan struktur mirip blockchain untuk memastikan ketersediaannya. Oleh karena itu, tidak semua data perlu direkam di blockchain. Misalnya, dalam permainan, konten obrolan pengguna umumnya tidak penting dan bisa dibuang, sehingga tidak perlu dimasukkan ke dalam blockchain.
2. Ini bisa mengekspresikan keadaan lengkap dunia. Dalam banyak skenario, seperti dalam permainan, ekspresi ini tidak selalu mengimplikasikan tingkat pelacakan yang tinggi - sebuah akumulator sederhana sudah cukup, yang berarti bahwa struktur data seperti pohon Merkle tidak selalu diperlukan. Namun, tidak peduli struktur data apa yang digunakan untuk mewakili keadaan dunia, penting bahwa keadaan dunia dari basis data dunia dapat diekspresikan dalam bentuk ringkasan.
3. Setiap fungsi yang dapat menyebabkan perubahan pada basis data dunia disebut fungsi transisi keadaan, dan harus dienkapsulasi dalam runtime transisi keadaan. Setiap modifikasi pada basis data dunia di luar runtime harus dianggap ilegal dan ditolak.
4. Antarmuka input dan output harus sesuai dengan desain Input Interpreter dan Block Proposer. Ini relatif sederhana dan tidak akan dijelaskan secara rinci di sini.

Struktur organisasi berikut adalah elemen penting dari STR ini. Tabi akan menyediakan SDK secara default untuk memudahkan pengembang dalam membuat runtime.

World DB

Dalam praktiknya, sebuah game atau aplikasi kemungkinan besar akan menggunakan lebih dari satu database, dan database tersebut mungkin berbeda jenis. Mari kita asumsikan bahwa sebuah game tertentu menggunakan baik database relasional maupun database nilai-kunci.

Berikut ini adalah contoh database relasional sederhana:

1. UID: Mewakili pengguna unik, yang dapat berupa kunci publik atau pengenal lainnya.
2. Nonce: digunakan untuk mencegah serangan replay.
3. Bidang data tambahan: jenis data apa pun.

Ini adalah database kunci-nilai sederhana:

Fungsi Transisi Negara

Ini adalah fungsi transisi negara yang sederhana. Ketika fungsi ini menerima input dari pengguna, ia hanya mengalikannya dengan 5 dan memodifikasi data di database relasional.

Akumulator Kondisi Dunia

Kita dapat membuat akumulator hash sederhana untuk mewakili keadaan dunia:

A_s+1 = hash(A_s + hash(query))

Metode ini memastikan bahwa setelah setiap modifikasi pada database dunia, akan selalu ada keadaan yang unik dan pasti yang sesuai dengan modifikasi tersebut.

Penting untuk dicatat bahwa setiap fungsi transisi negara harus melaksanakan metode ini. Persyaratan ini dapat ditegakkan menggunakan modifier, antarmuka, hook, atau mekanisme spesifik bahasa lainnya. Karena karakteristik yang berbeda dari berbagai bahasa pemrograman, kami tidak akan mendalami detail-detail spesifik di sini.

Proses pembaruan untuk database nilai-kunci (KVDB) mengikuti prinsip yang sama.

Nomor Acak

Fungsi transisi negara tidak boleh mencakup angka acak, karena hal ini akan menyebabkan hasil yang berbeda saat divalidasi oleh verifikator yang berbeda, yang memecahkan konsistensi. Angka acak harus dimasukkan sebagai bagian dari parameter input sistem.

Ringkas

Dari contoh di atas, kita dapat melihat bahwa Lapisan Eksekusi Omni Tabi Chain memberikan fleksibilitas yang signifikan kepada pengembang game melalui pendekatan modular. Karena keterbatasan ruang, kita tidak dapat membahas semua detail di sini, tetapi poin inti yang disebutkan sudah cukup untuk menunjukkan bahwa solusi Tabi Chain ini praktis dan inovatif.

Dalam ekosistem Web3 saat ini, karya-karya yang dikembangkan pada rantai dan mesin virtual yang berbeda umumnya kurang portabel. Bagi game Web2 untuk beralih ke Web3, seringkali berarti menulis ulang game dalam bahasa dan lingkungan yang tidak familiar, menghadapi berbagai pembatasan yang tidak bisa dimengerti.

Dengan Tabi, pengembang dapat menggunakan bahasa asli, platform pengembangan, dan mesin mereka. Mereka hanya perlu melakukan adaptasi dan modifikasi sederhana, mirip dengan memanggil SDK, untuk membawa proyek-proyek mereka ke dunia blockchain. Hal ini menghasilkan peningkatan efisiensi eksponensial dan pengurangan kompleksitas.

Kami berharap Tabi Chain dapat menjadi katalisator bagi adopsi massal permainan Web3, menarik pengembang game berbakat Web2 dan membawa game yang benar-benar menghibur dan dapat dimainkan ke ruang Web3.

Disclaimer:

1. Artikel ini dicetak ulang dari [Web3 Gate]. Semua hak cipta milik penulis asli [罗奔奔]. Jika ada keberatan dengan cetak ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata merupakan milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.