Mengapa kita membutuhkan Account Abstraction?

Masih banyak masalah yang belum terpecahkan di bidang blockchain saat ini. Diantaranya, kesulitan menggunakan blockchain, yaitu pengalaman pengguna (UX) berinteraksi dengan rantai, harus menjadi area yang paling banyak dikritik oleh publik.

Misalnya, banyak orang berpikir bahwa menggunakan kunci lebih rumit daripada menggunakan email untuk mengelola akun; manajemen kunci sulit dan tidak aman; dan setiap transfer (seperti USDC) memerlukan konsumsi token asli (seperti Ether dan Sol), yang berlawanan dengan intuisi.

Dalam konteks ini, semakin banyak orang mengalihkan perhatian mereka ke bidang account abstraction untuk meningkatkan pengalaman pengguna interaksi on-chain dan memfasilitasi adopsi massal.

Dalam proses eksplorasi, Ethereum mengusulkan solusi account abstraction seperti ERC-4337, EIP-3074, dan EIP-7702. L1 lainnya seperti Solana memiliki fitur yang memungkinkan account abstraction tingkat protokol seperti Program Derived Addresses (PDA), dan Cosmos juga memiliki desain serupa seperti x/authz dan Fee Abstraction Module. Dalam artikel ini, kami akan memperkenalkan dan membandingkan solusi yang disebutkan di atas, memilah seluk-beluk desain solusi yang berbeda, dan menunjukkan trade-off dan pertimbangan solusi yang berbeda.

Background

EOA vs Akun Kontrak

Akun Milik Eksternal (EOA) dan Akun Kontrak adalah dua jenis akun yang didefinisikan dalam whitepaper Ethereum. Akun EOA dikendalikan oleh kunci pribadi, dan pengguna dapat menandatangani berbagai transaksi melalui kunci pribadi untuk mengontrol aset di akun. Kontrak akun dikendalikan oleh kode akun itu sendiri, dan akun lain dapat membuat kontrak akun menjalankan logika tertentu dengan memanggil kode kontrak akun.

Abstraksi

Akun Konsep akun abstrak dapat ditelusuri kembali ke 2016 (https://github.com/ethereum/EIPs/issues/86). account abstraction didasarkan pada dan dibangun di atas dua jenis akun saat ini di Ethereum — EOA dan akun kontrak. Ini akan meningkatkan pengalaman interaktif pengguna Ethereum melalui cara-cara berikut:

1. Memungkinkan pengguna untuk menggunakan beberapa tanda tangan, seperti Schnorr, BLS, tanda tangan pasca-kuantum, dll.;
2. Memungkinkan pengguna membayar biaya gas menggunakan token ERC20 atau logika pembayaran khusus;
3. Memungkinkan pengguna untuk mengambil akun mereka menggunakan email, media sosial, dll.;
4. Memungkinkan pengguna untuk mengelola dana di akun mereka dengan izin terperinci, seperti menetapkan batas penarikan harian;
5. Memungkinkan beberapa operasi on-chain dilakukan dalam satu transaksi atom. Misalnya, pengguna dapat menyelesaikan operasi persetujuan dan swap dalam transaksi DEX dengan satu tanda tangan.

Ethereum Peta jalan

Peta jalan Ethereum (https://ethereum.org/en/roadmap/) menyoroti rute peningkatan Ethereum di masa mendatang. Saat ini, sebagian besar penelitian di komunitas Ethereum berkisar pada peta jalan Ethereum. Abstraksi akun adalah bagian penting dari ini:

Sumber: https://x.com/VitalikButerin/status/1741190491578810445

Komunitas Ethereum berharap untuk membangun ERC-4337 dan menerapkan solusi account abstraction di dalam protokol, melalui proposal seperti EIP-3074 atau EIP-7702, dan akhirnya mencapai Endgame account abstraction.

Terlepas dari peningkatan pengalaman pengguna, Endgame account abstraction juga penting untuk komputasi anti-kuantum Ethereum, karena algoritma ECDSA yang digunakan oleh akun EOA saat ini tidak aman di era komputasi kuantum. Mengadopsi account abstraction mendukung tanda tangan pasca-kuantum yang melindungi akun pengguna dari ancaman komputasi kuantum yang terus berkembang.

EIP-3074 vs ERC-4337

Untuk memahami akun abstrak akun, kita perlu memahami cara kerja EOA. Gambar di bawah ini adalah proses pembelian dan penjualan token yang paling umum pada rantai:

Secara umum, pengguna perlu mengeluarkan dua transaksi saat membeli dan menjual: pertama-tama beri wewenang kepada Uniswap untuk mentransfer USDC mereka untuk swap, dan kemudian kirim permintaan transaksi lain ke Uniswap untuk melakukan tindakan tersebut. Uniswap mentransfer USDC pengguna akun dan mengirimkan jumlah ETH yang sesuai kepada pengguna sesuai dengan harga saat ini.

ERC-4337 menggabungkan dua transaksi di atas menjadi satu:

Seperti dapat dilihat dari gambar di atas, pengguna perlu menandatangani dua kali untuk mengotorisasi bundler untuk mengoperasikan aset pengguna di akun 4337 yang berbeda dari akun EOA pengguna. Setelah bundler mendapatkan otorisasi, ia menggabungkan konten resmi ke dalam bundel dan mengeluarkannya untuk menyelesaikan transaksi. Pada saat yang sama, jika pengguna tidak memiliki token Ethereum untuk biaya gas, peran paymaster juga dapat diperkenalkan, memungkinkan paymaster untuk membayar biaya gas dan mendapatkan token ERC20 dengan nilai yang sama dari pengguna.

EIP-3074 dan ERC-4337 memiliki beberapa kesamaan, tetapi metode implementasi EIP-3074 protokol Ethereum:

Di ERC-4337, kami memberi wewenang kepada Bundler untuk menangani aset di dompet kontrak pintar on-chain kami melalui tanda tangan. Pada EIP-3074, bundler berwenang untuk langsung menangani aset di dompet EOA kami melalui tanda tangan. Dalam pesanan untuk melakukan ini, komunitas Ethereum perlu menambahkan dua opcode baru ke Ethereum protokol: AUTH dan AUTHCALL.

AUTH digunakan untuk memverifikasi apakah perilaku bundler dalam memproses aset akun EOA pengguna diotorisasi, dan AUTHCALL digunakan untuk "mengelabui" kontrak pintar interaksi pengguna (dalam contoh kami, USDC dan Uniswap), membuat kontrak pintar berpikir bahwa transaksi tersebut berasal dari akun EOA pengguna. Keuntungannya adalah pengelola Uniswap dan USDC tidak perlu meningkatkan smart contract yang diterapkan, sekaligus, akun EOA dapat menikmati fungsi account abstraction.

Perbandingan antara EIP-3074 dan ERC-4337

Di komunitas Ethereum, EIP umumnya mengacu pada proposal yang memerlukan peningkatan Ethereum untuk didukung, sedangkan ERC mengacu pada spesifikasi yang dapat didukung tanpa peningkatan Ethereum.

Oleh karena itu, dapat dilihat dari penamaan dua skema account abstraction bahwa ERC-4337 lebih mudah diterapkan daripada EIP-3074, karena ERC-4337 tidak memerlukan hard fork dari jaringan Ethereum. Ini juga salah satu alasan mengapa ERC-4337 telah diluncurkan dan semakin banyak digunakan pada poligon dan basis, tetapi EIP-3074 baru saja diterima oleh Ethereum All Core Developers Execution Call (ACDE) ke-183.

Sumber: https://dune.com/niftytable/account-abstraction

Selain itu, ERC-4337 mengharuskan pengguna untuk memigrasikan akun saat ini mereka ke akun kontrak baru dan mengharuskan DApp dukungan agar EIP-1271 berfungsi. EIP-3074 tidak memerlukan dukungan tambahan ini. Ini adalah alasan utama rendahnya tingkat adopsi ERC-4337. Pada saat yang sama, ERC-4337 tidak dapat dukungan satu tanda tangan untuk mengotorisasi beberapa operasi on-chain tanpa memperkenalkan kontrak multi-panggilan perantara, tetapi EIP-3074 dapat, yang juga menyebabkan keterbatasan ERC-4337.

Namun, EIP-3074 juga memiliki masalah sendiri. Yang paling penting adalah bahwa kode operasi AUTH memiliki izin yang terlalu tinggi, yang memungkinkan penyerang untuk sepenuhnya mengontrol akun EOA pengguna. Lagi pula, long peretas menipu tanda tangan AUTH Anda, ia dapat membuang aset di dompet EOA Anda. Mengingat serangan phishing saat ini merajalela, dan kebanyakan menipu tanda tangan pengguna, begitu EIP-3074 diterapkan, ini akan menjadi masalah yang lebih serius.

Dalam hal ini, lightclient, salah satu penulis EIP-3074, telah mengusulkan metode mitigasi untuk mencegat tanda tangan berbahaya di tingkat dompet. Untuk detailnya, silakan merujuk ke: https://x.com/lightclients/status/1778823652584120497. ERC-4337 tidak memiliki masalah ini, meskipun peretas masih dapat menipu pengguna agar menandatangani UserOps berbahaya. Hal ini disebabkan oleh kesulitan bagi UserOp untuk mendapatkan otoritas pembuangan atas semua aset dalam akun pengguna. Pada saat penulisan, pengembang di ACDE setuju untuk menghapus EIP-3704 dari Pectra Devent 0 dan memasukkan EIP-7702 di Pectra Devnet 1 berikutnya.

Apa yang berubah pada EIP-7702?

EIP-7702 mencoba mengintegrasikan manfaat EIP-3074 dan ERC-4337 untuk membentuk jalur tengah. Pengguna mengirim operasi yang ditandatangani ke bundler. Ketika bundler mengirim transaksi ke rantai, akun EOA pengguna untuk sementara akan menjadi akun kontrak pintar seperti 4337 akun. Selanjutnya, mirip dengan kemajuan AUTH di EIP-3074, akun kontrak pintar akan memvalidasi operasi bundler resmi pengguna. Kemudian, sama seperti AUTHCALL, lakukan operasi yang disahkan oleh pengguna. Setelah melakukan transaksi, pengguna akun akan dikembalikan ke akun EOA biasa.

Manfaat EIP-7702 adalah sebagai berikut:

1. Mewarisi semua keuntungan EIP-3074: tidak mengharuskan pengguna untuk beralih dari akun EOA ke akun kontrak pintar dengan alamat baru; dapat melakukan beberapa operasi dalam satu transaksi atom;
2. Kode akun kontrak pintar dan infrastruktur ERC-4337 dapat digunakan kembali;
3. account abstraction kontrak pintar yang diwakili oleh ERC-4337 dan solusi account abstraction EOA yang diwakili oleh EIP-3074 dapat digabungkan untuk mencegah Ethereum terpecah menjadi dua sistem account abstraction yang berbeda dan membuka jalan bagi Akun Abstraksi Endgame di peta jalan Ethereum;
4. Dua opcode AUTH dan AUTHCALL tidak akan ditambahkan ke EVM Ethereum: dengan mempertimbangkan akun roadmap Ethereum, akun EOA akan diubah menjadi account abstraction di masa mendatang, dan kedua opcode ini akan menjadi berlebihan.

Di luar itu, EIP-7702 mewarisi semua risiko keamanan dari EIP-3074.

Komunitas memutuskan untuk memasukkan EIP-7702 dalam peningkatan Pectra berikutnya pada tahun 2025. Jika diterapkan, itu akan sangat mengubah ekosistem Ethereum dan membawa peningkatan bertahap pada versi infrastruktur account abstraction ERC-4337 saat ini.

Solana's Program Derived Alamat

Abstraksi Akun pada Solana

account abstraction Solana mirip dengan ERC-4337 Ethereum. Mereka adalah akun yang berasal dari akun asli (mirip dengan akun EOA), mirip dengan 4337 akun kontrak. Sebelum memahami account abstraction Solana, perlu dipahami model akun yang digunakan oleh Solana.

Secara garis besar, akun dapat diklasifikasikan sebagai akun yang dapat dieksekusi yang dapat mengeksekusi kode atau akun yang tidak dapat dieksekusi yang tidak dapat melakukannya. Memeriksa ini lebih lanjut, ada tiga jenis akun di Solana: Program Asli, Akun Program, dan Akun Data.

Program asli adalah bagian dari implementasi validator dan menyediakan fungsi inti untuk jaringan Solana seperti pembuatan akun data baru dan program khusus. Akun program adalah program kustom yang berisi kode yang dapat dieksekusi. Akun data dapat menyimpan data dan mengelola status program seperti yang ditentukan oleh akun program pemiliknya.

Model akun ini secara native memungkinkan akun program untuk membuat dan mengelola akun tertentu, menawarkan pengembang kemampuan untuk menentukan aturan kustom dan logika untuk mengelolanya. Diaktifkan oleh model akun ini, Program Derived Alamat (PDA), sejenis akun data, memperluas kemungkinan kemampuan account abstraction pada Solana dari meningkatkan keamanan pengguna melalui dompet multisig dan otentikasi dua faktor untuk memungkinkan mekanisme pemulihan sosial antara lain.

Program Turunan Alamat

Untuk konteksnya, semua akun terletak pada kurva Ed25519 dan memiliki pasangan kunci publik-pribadi. PDA, yang terletak di luar kurva Ed25519, adalah string 32 byte yang diturunkan secara deterministik yang terlihat seperti kunci publik dan tidak dilengkapi dengan kunci pribadi yang sesuai. PDA memungkinkan pengembang untuk membuat aturan khusus dan mekanisme tanda tangan transaksi yang dapat memungkinkan pemilik akun program PDA untuk secara mandiri melakukan transaksi atas nama PDA, sepenuhnya diakui dan didukung oleh jaringan Solana.

PDA dan Abstraksi Akun

Oke sekarang kita mengerti bagaimana PDA diturunkan, Anda mungkin bertanya-tanya bagaimana konsep-konsep ini terkait dengan account abstraction. Abstraksi akun terjadi di bawah tenda melalui kinerja fungsi yang dikenal sebagai Cross Program Invocation (CPI).

CPI adalah fungsi yang memungkinkan program untuk memanggil instruksi dari program lain, memungkinkan untuk komposabilitas program Solana. Ketika sebuah program memulai CPI baik melalui invoke_signed, program dapat menandatangani atas nama PDA yang diturunkan.

Sumber: Solana

Untuk memverifikasi keabsahan transaksi yang melibatkan PDA, runtime Solana secara internal memanggil create_program_address menggunakan signers_seeds dan program_id program panggilan. Jika PDA yang valid ditemukan, runtime akan mengaitkan PDA dengan program pemanggilan dan mengenali program sebagai penandatangan resmi.

Saat ini, Squads sedang mengembangkan solusi account abstraction pada Solana berdasarkan PDA. Namun, produk yang disediakan oleh Squads saat ini lebih mirip dengan solusi akun kontrak pintar Gnosis Safe dan belum sepenuhnya mengembangkan fungsinya account abstraction.

Manfaat PDA

1. Eksekusi kontrak pintar otomatis: PDA memungkinkan desain kontrak pintar yang lebih kompleks yang dapat secara mandiri melakukan beberapa operasi atas nama pengguna melalui pemanggilan lintas program.
2. Pengalaman pengguna yang ditingkatkan: Pengguna tidak perlu mengelola banyak transaksi atau terkena kompleksitas teknis.
3. Peningkatan keamanan dan fleksibilitas: Tanpa kunci pribadi, ini mengurangi risiko kompromi kunci. PDA dapat digunakan untuk dompet multisig atau mengakomodasi model tata kelola fleksibel lainnya yang mengurangi satu titik risiko dan sangat berguna untuk organisasi yang mengelola sumber daya bersama yang besar.

Keterbatasan PDA

1. PDA, meskipun bermanfaat dalam meletakkan dasar untuk kemampuan account abstraction, dapat menjadi rumit untuk diterapkan dibandingkan dengan akun keypair.
2. Dan seperti ERC-4337, ini mengharuskan pengguna untuk melakukan migrasi akun ke akun baru yang dapat menekan tingkat adopsi Solana account abstraction.

Abstraksi Akun tentang Cosmos (Authz &; Fee Grant)

Cosmos x/authz

Dengan account abstraction yang semakin mengambil mindshare pengembang, authz, bagian dari Cosmos SDK inti, diluncurkan untuk memungkinkan akun melakukan tindakan tertentu atas nama akun lain melalui penggunaan hibah otorisasi yang serupa dengan EIP-3074 dan EIP-7702.

Authz hadir dengan beberapa jenis otorisasi yang telah ditentukan sebelumnya yang mendelegasikan kinerja tindakan tertentu seperti mempertaruhkan ke penerima hibah, meningkatkan pengalaman pengguna sebagai hasilnya.

Dengan authz, 3 jenis Otorisasi dapat diberikan:

1. Otorisasi Generik. Pemberian otorisasi ini memberikan izin tidak terbatas bagi penerima hibah untuk mengeksekusi pesan atas nama pemberi hibah.
2. KirimOtorisasi. Otorisasi ini, seperti persetujuan di ERC20, berupaya memberi penerima hibah akses ke batas pengeluaran positif yang menentukan jumlah maksimum yang dapat dibelanjakan atas nama pemberi hibah.
3. StakeAuthorization. Hibah ini memungkinkan penerima hibah untuk mengelola tindakan staking seperti mendelegasikan, membatalkan delegasi, atau mendelegasikan kembali atas nama pemberi hibah.

Hibah terdiri dari byte alamat pemberi, byte alamat penerima hibah, dan jenis otorisasi. Jangka waktu juga dapat didefinisikan untuk membatasi izin dalam jangka waktu tertentu. Di akhir setiap blok, jaringan akan menghapus hibah yang kedaluwarsa melalui proses yang disebut pemangkasan.

Memahami Kerangka Kerja Operasional

Authz dapat digunakan untuk memberikan otorisasi untuk berbagai tindakan, namun untuk kesederhanaan, kami akan memeriksa cara kerja authz untuk memungkinkan transaksi suara umum.

1. Menerapkan antarmuka otorisasi sebelum otorisasi apa pun dapat dijalankan. Pada fase ini, jenis pesan juga akan didefinisikan yang dalam hal ini akan menjadi MsgVote. Di sini, kita melihat otorisasi hibah dari Alice untuk tindakan pemungutan suara tata kelola.
2. Bob menghasilkan transaksi suara yang tidak ditandatangani.
3. Bob menghasilkan transaksi suara yang ditandatangani dan dieksekusi dari penerima hibah. Transaksi selesai dan otorisasi akan dihapus jika sudah kadaluarsa.

Manfaat yang dibawa authz?

1. Keamanan operasional: Validator dan pengguna lain dapat memberikan izin kepada akun terpisah untuk memberikan suara pada proposal tata kelola atau melakukan tindakan tertentu, meningkatkan keamanan akun dan mengurangi beban keamanan.
2. Operasi yang disederhanakan: Transaksi dapat dilakukan dengan memerlukan akses ke kunci validator, transaksi dompet multisig juga dapat disederhanakan menggunakan satu transaksi untuk memberikan Authz kepada penerima akun.
3. Tidak perlu migrasi: Mirip dengan EIP-3074 dan EIP-7702, operasi otorisasi terjadi di akun asli pengguna. Pengguna tidak perlu mentransfer aset mereka dari akun asli ke akun baru untuk mengaktifkan account abstraction.
4. DAO Efisiensi dan Fleksibilitas Operasional: Sebagian hak eksekusi dapat diberikan kepada anggota DAO individu untuk tindakan tertentu.
5. Staking Peracikan Hadiah: Authz memfasilitasi penggunaan layanan restaking dan setara untuk peracikan otomatis hadiah staking.

Batasan dan risiko terhadap Authz:

Perhatikan jenis transaksi yang Anda otorisasi melalui Authz. Otorisasi berbahaya dapat menjalankan berbagai jenis otorisasi yang dapat merugikan pengguna.

1. GenericAuthorization: memberikan izin tak terbatas untuk mengeksekusi Msg yang disediakan atas nama pemberi. Kecuali sepenuhnya menyadari apa yang Anda tandatangani, sangat disarankan untuk menghindari penandatanganan jenis otorisasi tersebut. Beberapa dompet mungkin juga tidak memberikan peringatan saat menandatangani transaksi Authz.
2. SendAuthorization: Memungkinkan penerima hibah untuk mengirim jumlah maksimum token yang dapat dibelanjakan penerima hibah jika tidak ditentukan oleh pemberi hibah. Penting juga untuk memverifikasi Daftar Izin, yang menentukan alamat spesifik tempat penerima hibah dapat mengirim token.

Fee Grant Module Rintangan

lain untuk pengalaman pengguna yang membuat frustrasi banyak orang adalah perlunya pengguna blockchain untuk memegang berbagai token asli secara pesanan untuk berinteraksi dengan ekosistem yang berbeda ini. Ini mencemari pengalaman pengguna secara keseluruhan terutama bagi penduduk asli non-kripto yang pertama kali terpapar pada segudang rantai yang ada di ekosistem Cosmos.

Namun, rintangan ini telah melihat terobosan dengan integrasi Modul Hibah Biaya. Mirip dengan kontrak paymaster yang memungkinkan account abstraction di Ethereum, Modul Hibah Biaya di Cosmos memungkinkan pemberi untuk memberikan tunjangan biaya kepada penerima hibah, membayar sebagian atau seluruh biaya transaksi. Dana tersebut tetap berada dalam kendali pemberi hibah dan dapat mencabut tunjangan hibah kapan saja.

Jenis Hibah Biaya

Tunjangan Biaya dapat dikategorikan menjadi dua jenis: BasicAllowance dan PeriodicAllowance.

BasicAllowance memungkinkan penerima hibah untuk menggunakan biaya dari pemberi akun sampai batas pengeluaran atau waktu kedaluwarsa tercapai. Hibah kemudian akan dihentikan dari negara. Penting untuk dicatat bahwa BasicAllowance menerapkan pemberian biaya satu kali. Jika batas pengeluaran dan waktu kosong, tidak ada kedaluwarsa dan batas pengeluaran pada tunjangan biaya.

PeriodicAllowance memungkinkan hibah biaya diperpanjang secara berkala setelah setiap periode waktu yang ditentukan. Period_spend_limit menentukan jumlah maksimum koin yang dapat dihabiskan dalam periode tersebut. Period_reset melacak kapan periode berikutnya harus terjadi dan period_can_spend melacak jumlah koin yang tersisa sebelum periode baru dimulai.

Memahami Kerangka Kerja Operasional

Menggunakan AllowedMsgAllowance membuat penyisihan untuk jenis pesan tertentu. Tunjangan dapat berupa Tunjangan Dasar atau Tunjangan Berkala. Jika waktu kedaluwarsa ditetapkan, FeeAllowance akan diantrekan di negara bagian dengan awalan kedaluwarsa ditambahkan ke hibah dan Endblocker memeriksa status FeeAllowanceQueue untuk hibah yang kedaluwarsa, memangkas apa pun jika ditemukan. Selain MsgGrantAllowance, tunjangan biaya juga dapat dicabut menggunakan MsgRevokeAllowance.

Secara bersama-sama, modul Authz dan Fee Grant membuka kasus penggunaan yang inovatif dan beragam yang pada akhirnya membangun pengalaman pengguna yang lebih baik di ekosistem Cosmos.

Kesimpulan

Abstraksi Akun Per 27 Mei 2024, angka diperkirakan.

Dengan persetujuan ETF spot BTC dan ETF ETH, permintaan institusional dan ritel telah meningkat secara signifikan, menjanjikan untuk mengantarkan gelombang baru pengguna yang ingin mendapatkan eksposur ke industri. Abstraksi akun akan menjadi narasi penting tahun ini karena protokol dan dapp berusaha menciptakan pengalaman yang mulus untuk memperluas komunitas mereka.

DISCLAIMER

Materi ini hanya untuk informasi umum, dan bukan merupakan, juga tidak boleh ditafsirkan sebagai, segala bentuk hasil penelitian, saran profesional, ajakan, penawaran, rekomendasi, atau strategi perdagangan. Tidak ada jaminan, representasi, jaminan atau usaha, tersurat maupun tersirat, yang dibuat mengenai keadilan, akurasi, ketepatan waktu, kelengkapan atau kebenaran informasi keuangan dan pasar umum, analisis, dan / atau pendapat yang diberikan pada laporan ini, dan tidak ada kewajiban atau tanggung jawab yang diterima oleh HashKey Capital sehubungan dengan penggunaan atau ketergantungan pada informasi tersebut. Setiap informasi dalam laporan ini dapat berubah tanpa pemberitahuan. Laporan ini belum ditinjau oleh Securities and Futures Commission of Hong Kong, Monetary Authority of Singapore atau otoritas pengatur di Hong Kong atau Singapura.

Perlu diketahui bahwa aset digital, termasuk mata uang kripto, sangat fluktuatif dan memiliki risiko pasar. Nilai aset digital dapat berfluktuasi secara signifikan, dan tidak ada jaminan keuntungan atau pelestarian modal. Anda harus hati-hati mempertimbangkan toleransi risiko dan situasi keuangan Anda sendiri sebelum membuat keputusan apa pun.

Distribusi laporan ini mungkin dibatasi di yurisdiksi tertentu. Materi ini bukan merupakan distribusi informasi apa pun atau pembuatan penawaran atau ajakan apa pun oleh yurisdiksi mana pun di mana tindakan tersebut tidak diizinkan atau kepada siapa pun yang melanggar hukum untuk mendistribusikan laporan semacam itu.

Tetap update dengan berita HashKey Capital terbaru -

Situs web — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

Penafian:

1. Artikel ini dicetak ulang dari [Medium]. Semua hak cipta adalah milik penulis asli [HashKey Capital]. Jika ada keberatan dengan cetak ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.

2. Penafian Kewajiban: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata milik penulis dan bukan merupakan saran investasi.

3. Penerjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.