TON is an innovative blockchain that incorporates novel concepts in smart contract design. Coming a number of years after Ethereum, the builders of TON had the advantage of being able to evaluate the successes and failures of the Ethereum Virtual Machine (EVM) model. For more on this, check out six unique aspects of TON blockchain that will surprise Solidity developers.

In this article, we’ll go through a couple of the most interesting features of the TON blockchain, then we’ll go through a list of best practices for developers programming smart contracts in FunC.

Contract Sharding

When developing contracts for the EVM, you generally break up the project into several contracts for convenience. In some cases, it is possible to implement all the functionality in one contract, and even where contract splitting was necessary (for example, Liquidity Pairs in the Automated Market Maker) this did not lead to any special difficulties. Transactions are executed in their entirety: either everything works out, or everything reverts.

In TON, it is strongly recommended to avoid “unbounded data structures” and split a single logical contract into small pieces, each of which manages a small amount of data. The basic example is the implementation of TON Jettons. This is TON's version of Ethereum's ERC-20 token standard. Briefly, we have:

  1. One jetton-minter that stores total_supply, minter_address, and a couple of refs: token description (metadata) and jetton_wallet_code.
  2. And a lot of jetton-wallet, one for each owner of these jettons. Each such wallet stores only the owner's address, their balance, jetton-minter address, and a link to jetton_wallet_code.

This is necessary so that the transfer of Jettons occurs directly between wallets and does not affect any high-load addresses, which is fundamental for the parallel processing of transactions.

That is, get ready so that your contract turns into a "group of contracts", and they will actively interact with each other.

What follows from this?

Partial Execution of Transactions is Possible

A new unique property appears in the logic of your contract: partial execution of transactions.

For example, consider the message flow of a standard TON Jetton:

TON Jetton message flow

As follows from the diagram,

  1. sender sends an op::transfer message to its wallet (sender_wallet)
  2. sender_wallet reduces the token balance
  3. sender_wallet sends an op::internal_transfer message to the recipient's wallet (destination_wallet)
  4. destination_wallet increases its token balance
  5. destination_wallet sends op::transfer_notification to its owner (destination)
  6. destination_wallet returns excess gas with op::excesses message on response_destination (usually sender)

Note that if the destination_wallet was unable to process the op::internal_transfer message (an exception occurred or the gas ran out), then this part and subsequent steps will not be executed. But the first step (reducing the balance in sender_wallet) will be completed. The result is a partial execution of the transaction, an inconsistent state of the Jetton, and, in this case, the loss of money.

In the worst case scenario, all the tokens can be stolen in this way. Imagine that you first accrue bonuses to the user, and then send an op::burn message to their Jetton wallet, but you cannot guarantee that the op::burn will be processed successfully.

Tip #1: Always Draw Message Flow Diagrams

Even in a simple contract like a TON Jetton, there are already quite a few messages, senders, receivers, and pieces of data contained in messages. Now imagine how it looks when you’re developing something a little more complex, like a decentralized exchange (DEX) where the number of messages in one workflow can exceed ten.

An example message flow demonstrating the importance of visualization

At CertiK, we use the DOT language to describe and update such diagrams during the course of the audit. Our auditors find that this helps them visualize and understand the complex interactions within and between contracts.

Tip #2: Avoid Fails and Catch Bounced Messages

Using the message flow, first define the entry point. This is the message that starts the cascade of messages in your group of contracts (“consequences”). It is here that everything needs to be checked (payload, gas supply, etc.) in order to minimize the possibility of failure in subsequent stages.

If you are not sure whether it will be possible to fulfill all your plans (for example, whether the user has enough tokens to complete the deal), it means that the message flow is probably built incorrectly.

In subsequent messages (consequences), all throw_if()/throw_unless() will play the role of asserts rather than actually checking something.

Many contracts also process bounced messages just in case.

For example, in TON Jetton, if the recipient's wallet cannot accept any tokens (it depends on the logic for receiving), then the sender's wallet will process the bounced message and return the tokens to its own balance.

() on_bounce (slice in_msg_body) impure {
    in_msg_body~skip_bits(32);  ;;0xFFFFFFFF

    (int balance, slice owner_address, slice jetton_master_address, cell jetton_wallet_code) = load_data();

    int op = in_msg_body~load_op();

    throw_unless(error::unknown_op, (op == op::internal_transfer) | (op == op::burn_notification));

    int query_id = in_msg_body~load_query_id();
    int jetton_amount = in_msg_body~load_coins();

    balance += jetton_amount;
    save_data(balance, owner_address, jetton_master_address, jetton_wallet_code);

In general, we recommend processing bounced messages, however, they can’t be used as a means of full protection from failed message processing and incomplete execution.

It takes gas to send a bounced message and process it, and if there isn’t enough provided by the sender, then no bounced.

Secondly, TON does not provide for a chain of jumps. This means a bounced message can't be re-bounced. For example, if the second message is sent after the entry message, and the second one triggers the third one, then the entry contract will not be aware of the failure of processing the third message. Similarly, if the processing of the first sends the second and the third, then the failure of the second will not affect the processing of the third.

Tip #3: Expect a Man-in-the-Middle of the Message Flow

A message cascade can be processed over many blocks. Assume that while one message flow is running, an attacker can initiate a second one in parallel. That is, if a property was checked at the beginning (e.g. whether the user has enough tokens), do not assume that at the third stage in the same contract they will still satisfy this property.

Recommendation #4: Use a Carry-Value Pattern

It follows from the previous paragraph that messages between contracts must carry valuables.

In the same TON Jetton, this is demonstrated: sender_wallet subtracts the balance and sends it with an op::internal_transfer message to destination_wallet, and it, in turn, receives the balance with the message and adds it to its own balance (or bounces it back).

And here is an example of incorrect implementation. Why can't you find out your Jetton balance on-chain? Because such a question does not fit the pattern. By the time the response to the op::get_balance message reaches the requester, this balance could already have been spent by someone.

In this case, you can implement an alternative:

Carry-value pattern usage example

  1. master sends a message op::provide_balance to the wallet
  2. wallet zeroes its balance and sends back op::take_balance
  3. master receives the money, decides if it has enough, and either uses it (debits something in return) or sends it back to wallet
Tip #5: Return Value Instead of Rejecting

From the previous observation, it follows that your group of contracts will often receive not just a request, but a request along with a value. So you can't just refuse to execute the request (via throw_unless()), you have to send the Jettons back to the sender.

For example, a typical flow start (see TON Jetton message flow):

  1. sender sends an op::transfer message via sender_wallet to your_contract_wallet, specifying forward_ton_amount and forward_payload for your contract.
  2. sender_wallet sends an op::internal_transfer message to your_contract_wallet.
  3. your_contract_wallet sends an op::transfer_notification message to your_contract, delivering forward_ton_amount, forward_payload, and the sender_address and jetton_amount.
  4. And here in your contract in handle_transfer_notification() the flow begins.

There you need to figure out what kind of request it was, whether there is enough gas to complete it, and whether everything is correct in the payload. At this stage, you should not use throw_if()/throw_unless(), because then the Jettons will simply be lost, and the request will not be executed. It's worth using the try-catch statements available starting from FunC v0.4.0.

If something does not meet the expectations of your contract, the Jettons must be returned.

We found an example of this vulnerable implementation in a recent audit.

() handle_transfer_notification(...) impure {
    int jetton_amount = in_msg_body~load_coins();
    slice from_address = in_msg_body~load_msg_addr();
    slice from_jetton_address = in_msg_body~load_msg_addr();

    if (msg_value < gas_consumption) { ;; not enough gas provided
        if (equal_slices(from_jetton_address, jettonA_address)) {
            var msg = begin_cell()
                .store_uint(0x18, 6)
                .store_uint(1, 1 + 4 + 4 + 64 + 32 + 1 + 1)

As you can see, here the "return" is sent to jettonA_wallet_address, not sender_address. Since all decisions are made based on the analysis of in_msg_body, an attacker can forge a fake message and extract the money. Always send the return to sender_address.

If your contract accepts Jettons, it is impossible to know if it was indeed the expected Jetton that came, or just an op::transfer_notification from someone.

If your contract receives unexpected or unknown Jettons, they must also be returned.

TON Smart Contract Developer Must Control the Gas

In Solidity, gas is not much of a concern for contract developers. If the user provides too little gas, everything will be reverted as if nothing had happened (but the gas will not be returned). If they provide enough, the actual costs will automatically be calculated and deducted from their balance.

In TON, the situation is different:

  1. If there is not enough gas, the transaction will be partially executed.
  2. If there is too much gas, the excess must be returned. This is the developer’s responsibility.
  3. If a “group of contracts” exchanges messages, then control and calculation must be carried out in each message.

TON cannot automatically calculate the gas. The complete execution of the transaction with all its consequences can take a long time, and by the end, the user may not have enough toncoins in their wallet. The carry-value principle is used again here.

Tip #6: Calculate Gas and Check msg_value

According to our message flow diagram, we can estimate the cost of each handler in each of the scenarios and insert a check for the sufficiency of msg_value.

You can’t just demand with a margin, say 1 TON (the gas_limit on mainnet as of the date of writing) because this gas must be divided among the “consequences”. Let's say your contract sends three messages, then you can only send 0.33 TON to each. This means that they should “demand” less. It’s important to calculate the gas requirements of your whole contract carefully.

Things get more complicated if, during development, your code starts sending more messages. Gas requirements need to be rechecked and updated.

Tip #7: Return Gas Excesses Carefully

If excess gas is not returned to the sender, the funds will accumulate in your contracts over time. In principle, nothing terrible, this is just suboptimal practice. You can add a function for raking out excesses, but popular contracts like TON Jetton still return to the sender with the message op::excesses.

TON has a useful mechanism: SEND_MODE_CARRY_ALL_REMAINING_MESSAGE_VALUE = 64. When using this mode in send_raw_message(), the rest of the gas will be forwarded further with the message (or back) to the new recipient. It is convenient if the message flow is linear: each message handler sends only one message. But there are cases when it is not recommended to use this mechanism:

  1. If there are no other non-linear handlers in your contract. storage_fee is deducted from the balance of the contract, and not from the incoming gas. This means that over time, storage_fee can eat up the entire balance because everything that comes in has to go out.
  2. If your contract emits events, i.e. sends a message to an external address. The cost of this action is deducted from the balance of the contract, and not from msg_value.
() emit_log_simple (int event_id, int query_id) impure inline {
    var msg = begin_cell()
        .store_uint (12, 4)             ;; ext_out_msg_info$11 addr$00
        .store_uint (1, 2)              ;; addr_extern$01
        .store_uint (256, 9)            ;; len:(## 9)
        .store_uint(event_id, 256);     ;; external_address:(bits len)
        .store_uint(0, 64 + 32 + 1 + 1) ;; lt, at, init, body
    send_raw_message(msg, SEND_MODE_REGULAR);
  1. If your contract attaches value when sending messages or uses SEND_MODE_PAY_FEES_SEPARETELY = 1. These actions deduct from the balance of the contract, which means that returning unused is "working at a loss."

In the indicated cases, a manual approximate calculation of the surplus is used:

int ton_balance_before_msg = my_ton_balance - msg_value;
int storage_fee = const::min_tons_for_storage - min(ton_balance_before_msg, const::min_tons_for_storage);
msg_value -= storage_fee + const::gas_consumption;

if(forward_ton_amount) {
    msg_value -= (forward_ton_amount + fwd_fee);

if (msg_value > 0) {    ;; there is still something to return

var msg = begin_cell()
    .store_uint(0x10, 6)

Remember, if the value of the contract balance runs out, the transaction will be partially executed, and this cannot be allowed.

TON Smart Contract Developer Must Manage the Storage

A typical message handler in TON follows this approach:

() handle_something(...) impure {
    (int total_supply, <a lot of vars>) = load_data();
    ... ;; do something, change data
    save_data(total_supply, <a lot of vars>);

Unfortunately, we are noticing a trend: <a lot of vars> is a real enumeration of all contract data fields. For example,

int total_supply, int swap_fee, int min_amount, int is_stopped, int user_count, int max_user_count, 
slice admin_address, slice router_address, slice jettonA_address, slice jettonA_wallet_address, 
int jettonA_balance, int jettonA_pending_balance, slice jettonB_address, slice jettonB_wallet_address, 
int jettonB_balance, int jettonB_pending_balance, int mining_amount, int datetime_amount, int minable_time, 
int half_life, int last_index, int last_mined, cell mining_rate_cell, cell user_info_dict, cell operation_gas, 
cell content, cell lp_wallet_code
) = load_data();

This approach has a number of disadvantages.

First, if you decide to add another field, say is_paused, then you need to update the load_data()/save_data() statements throughout the contract. And this is not only labor-intensive, but it also leads to hard-to-catch errors.

In a recent CertiK audit, we noticed the developer mixed up two arguments in places, and wrote:

save_data(total_supply, min_amount, swap_fee, ...

Without an external audit performed by a team of experts, finding such a bug is very difficult. The function was rarely used, and both confused parameters usually had a value of zero. You really have to know what you’re looking for to pick up on an error like this.

Secondly, there is "namespace pollution". Let's explain what the problem is with another example from an audit. In the middle of the function, the input parameter read:

int min_amount = in_msg_body~load_coins();

That is, there was a shadowing of the storage field by a local variable, and at the end of the function, this replaced value was stored in storage. The attacker had the opportunity to overwrite the state of the contract. The situation is aggravated by the fact that FunC allows the redeclaration of variables: “This is not a declaration, but just a compile-time insurance that min_amount has type int.”

And finally, parsing the entire storage and packing it back on every call to every function increases the gas cost.

Tip #8: Use Nested Storage

We recommend the following storage organization approach:

() handle_something(...) impure {
    (slice swap_data, cell liquidity_data, cell mining_data, cell discovery_data) = load_data();
    (int total_supply, int swap_fee, int min_amount, int is_stopped) = swap_data.parse_swap_data();
    swap_data = pack_swap_data(total_supply + lp_amount, swap_fee, min_amount, is_stopped);
    save_data(swap_data, liquidity_data, mining_data, discovery_data);

Storage consists of blocks of related data. If a parameter is used in each function, for example, is_paused, then it is provided immediately by load_data(). If a parameter group is needed only in one scenario, then it does not need to be unpacked, it will not have to be packed, and it will not clog the namespace.

If the storage structure requires changes (usually adding a new field), then much fewer edits will have to be made.

Moreover, the approach can be repeated. If there are 30 storage fields in our contract, then initially you can get four groups, and then get a couple of variables and another subgroup from the first group. The main thing is not to overdo it.

Note that since a cell can store up to 1023 bits of data and up to 4 references, you will have to split the data into different cells anyway.

Hierarchical data is one of the main features of TON, let's use it for its intended purpose.

Global variables can be used, especially at the prototyping stage, where it is not entirely obvious what will be stored in the contract.

global int var1;
global cell var2;
global slice var3;

() load_data() impure {
    var cs = get_data().begin_parse();
    var1 = cs~load_coins();
    var2 = cs~load_ref();
    var3 = cs~load_bits(512);

() save_data() impure {

That way, if you find out that you need another variable, you just add a new global variable and modify load_data() and save_data(). No changes throughout the contract are needed. However, since there is a limitation on the number of global variables (no more than 31), this pattern can be combined with the "nested storage" recommended above.

Global variables are also often more expensive than storing everything on the stack. This, however, depends on the number of stack permutations, so it is a good idea to prototype with globals and, when storage structure is completely clear, to switch to on stack variables with a "nested" pattern.

Tip #9: Use end_parse()

Use end_parse() wherever possible when reading data from storage and from the message payload. Since TON uses bit streams with variable data format, it’s helpful to ensure that you read as much as you write. This can save you an hour of debugging.

Tip #10: Use More Helper Functions, and Avoid Magic Numbers

This tip is not unique to FunC but it is especially relevant here. Write more wrappers, and helper functions, and declare more constants.

FunC initially has an incredible amount of magic numbers. If the developer does not make any effort to limit their usage, the result is something like this:

var msg = begin_cell()
    .store_uint(0xc4ff, 17)         ;; 0 11000100 0xff
    .store_uint(config_addr, 256)
    .store_grams(1 << 30)           ;; ~1 gram of value
    .store_uint(0, 107)
    .store_uint(0x4e565354, 32)
    .store_uint(query_id, 64)
send_raw_message(msg.end_cell(), 1);

This is code from a real project, and it scares off newbies.

Fortunately, in recent versions of FunC, a couple of standard declarations can make the code clearer and more expressive. For example:

const int SEND_MODE_REGULAR = 0;

builder store_msgbody_prefix_stateinit(builder b) inline {
    return b.store_uint(4 + 2 + 1, 1 + 4 + 4 + 64 + 32 + 1 + 1 + 1);

builder store_body_header(builder b, int op, int query_id) inline {
    return b.store_uint(op, 32).store_uint(query_id, 64);

() mint_tokens(slice to_address, cell jetton_wallet_code, int amount, cell master_msg) impure {
    cell state_init = calculate_jetton_wallet_state_init(to_address, my_address(), jetton_wallet_code);
    slice to_wallet_address = calculate_address_by_state_init(state_init);
    var msg = begin_cell()

    send_raw_message(msg.end_cell(), SEND_MODE_REGULAR);

We love expressive code!


In this article, we’ve gone through some of the unique features developers will encounter when programming smart contracts on TON using FunC. We’ve also provided 10 tips we’ve learned throughout the course of our audits that will make your experience as smooth as possible.

We’re excited to be supporting the TON ecosystem and working with the many great projects being built on this new and innovative blockchain platform.

For an audit of your smart contract code, or to consult with our team of auditors and security experts, don’t hesitate to get in touch at

CertiK is a pioneer in blockchain security, leveraging best-in-class AI technology and expert manual review to protect and monitor blockchain protocols and smart contracts. Founded in 2018 by professors from Yale University and Columbia University, CertiK secures the Web3 world by applying cutting-edge innovations from academia to enterprise, enabling mission-critical applications to scale safely.

※본 리포트는 한화 드림플러스 인턴십 X 쟁글 리서치팀과의 협업으로 작성되었습니다.  

Written By: 이윤경, 조승희, 박희준

Reviewed By: KP, 포뇨



1. 들어가며

2. 지갑이란 무엇인가?

2-1. 지갑의 개요 - 키 구조와 수탁 방식을 중심으로

2-2. 메인 지갑 분석 - 메타마스크, 팬텀, 코인베이스, 렛저를 중심으로

3. 불편함이 많은 기존지갑, 이유는 시드구문에 있다

3-1. 대표적인 진입장벽, 시드구문 생성 및 관리

3-2. 유출 시 해킹 및 탈취 위험성

4. 최근 주목되는 지갑 솔루션은 Smart Contract 지갑과 MPC 지갑

4-1. Smart Contract 지갑과 계정 추상화(Account Abstraction)

4-2. MPC 지갑의 단일 실패 지점 제거

5. 미래의 웹3 생태계를 이끌 차세대 지갑 비즈니스

5-1. 지갑 확장 솔루션

5-2. 핀테크 서비스로 본 웹3 지갑의 슈퍼앱 발전 가능성

6. 지갑 시장 활성화를 가로막는 허들은 바로 규제

6-1. 국내 지갑 관련 규제인 KYC, 트래블룰

6-2. 국내 지갑 Klip, Dosi의 규제 대응 현황

6-3. 웁살라 시큐리티 등 신흥 솔루션 제시

7. 맺으며



1. 들어가며

작년 11월, 세계 3위 거래소인 FTX가 자산 건전성 논란 끝에 파산하였다. FTX의 창업자 뱅크먼 프리드가 거래소 고객의 돈을 알라메다 리서치의 채무와 지출을 갚는 데에 사용하고, 정치인들의 기부금으로 사용하는 등 횡령한 사실이 드러났다. 이러한 사건을 계기로 가상자산 거래소에 대한 신뢰도가 급격히 낮아져 중앙화 거래소에게 화폐를 수탁하는 방식이 아닌 개인의 지갑을 사용하여 자산을 관리하는 방식이 권장되기 시작했다. 대표적인 가상자산 거래소도 이에 대해 직접적으로 언급하였는데, 1위 거래소인 바이낸스의 CEO 창펑자오(CZ)는 “셀프 커스터디는 기본적인 권리에 해당한다. 당신이 이를 제대로 챙기고 있는지 확인해 보라”라고 강조하였고, 2위 거래소인 코인베이스의 CEO 브라이언 암스트롱은 “장기적으로 가상자산은 제삼자의 신뢰에 의존하지 않는 DeFi와 셀프 커스터디 지갑으로 더 나은 시스템을 구축할 수 있다”라고 전했다. 또한, 사태 이후 바이낸스는 하드웨어 지갑 제조사인 엔그레이브에 투자한다고 밝히며 셀프 커스터디가 가능한 하드웨어 지갑이 자산을 가장 안전하게 보관하는 방법 중 하나라고 언급하였다.

그러나 거래소 수탁 방식의 대체재로 제안된 셀프 커스터디, 하드웨어 지갑도 시드구문(seed phrase)의 불편함이라는 본질적 문제로 인해 온전한 지갑 솔루션이 되지 못한다. 이런 기존 지갑의 허점을 보완할 목적으로 새로운 형태의 지갑이 계속 등장하는 것처럼, 가상자산 지갑의 대중화로 나아가기 위한 노력이 최근까지도 여러 방면에서 일어나고 있다. 그렇다면 사용자들에게 필요한 지갑의 니즈는 무엇이고, 이를 충족하기 위해 지갑은 어떤 방향으로 나아가야 할까? 본 글에서는 시드구문와 관련된 현재 지갑의 문제점을 지적하고 이에 대한 솔루션을 분석한 후, 관련 비즈니스와 규제를 살펴보고자 한다.

2. 지갑이란 무엇인가?

2-1. 지갑의 개요 - 키 구조와 수탁 방식을 중심으로

가상자산 지갑은 블록체인상의 자산을 관리하고 디앱과 상호작용할 수 있도록 돕는 인터페이스이다. 지갑을 생성할 때에는 공개키와 개인키가 함께 생성되는데, 이때 공개키는 개인키를 통해 생성되지만, 공개키를 사용해서 개인키를 유추하는 것은 절대 불가능하다는 특징을 가진다. 대부분의 지갑이 사용하는 공개키 암호화란 송신자가 전달하고자 하는 메시지를 수신자의 공개키로 암호화하면, 수신자는 이를 자신의 개인키로 복호화하여 읽는 방식이다. 또 트랜잭션 수행 시, 트랜잭션 송신자는 자신의 개인키로 서명을 하고, 트랜잭션을 수신하는 검증자들은 송신자의 공개키를 통해 서명의 유효성을 검증한다.

이러한 지갑은 크게 수탁 지갑과 비수탁 지갑으로 나뉜다. 이 두 지갑의 차이는 개인 키를 관리하는 주체인데, 수탁 지갑은 개인키를 중앙화된 거래소가 관리하여 자산 거래 시 수탁자에게 이를 요청해야 하는 방식이다. 반면, 비수탁 지갑은 제삼자의 수탁자가 아닌 자신이 직접 개인키를 관리하고 거래를 서명하는 방식이다. 그렇기 때문에 자산에 대한 통제 권한과 이에 따르는 책임을 모두 개인이 가지게 된다. 이러한 방식의 비수탁 지갑을 ‘셀프 커스터디(self custody)’라고도 부른다.

2-2. 메인 지갑 분석 - 메타마스크, 팬텀, 코인베이스, 렛저를 중심으로

기존 지갑 시장에서 독점적인 지위를 가지던 이더리움의 ‘메타마스크’와 솔라나의 ‘팬텀’ 지갑 외에 신흥강자로 떠오르는 지갑을 소개해보고자 한다. 포브스에서 올해 1월 발간한 자료에 따르면, 소프트웨어 지갑에서는 Coinbase, 하드웨어 지갑에서는 Ledger가 최고의 가상자산 지갑으로 선정되었다.

A. 소프트웨어 지갑 1위 Coinbase

기존의 오픈소스 디앱 브라우저 지갑인 Toshi를 코인베이스로 이름을 바꾸며 업데이트하였다. Coinbase Exchange와 원활하게 연결되어 구매한 자산을 즉시 전송할 수 있다. 신용/직불 카드를 사용하여 지갑 내 가상자산 구매가 가능하고, 비트코인의 경우 코인 베이스 지갑의 모바일 앱을 통해서만 지원된다. 지갑 생성 시 설정한 ‘사용자 이름’으로 거래하기 때문에 높은 익명성이 보장된다.

B. 하드웨어 지갑 1위 Ledger

렛저 지갑은 Ledger Nano S 및 Ledger Nano X 지갑의 두 가지 하드웨어 지갑을 제공한다. 그중 렛저 나노 S는 2016년 출시되어 하드웨어 지갑의 원조라고 불리며, 렛저 나노 X는 2019년 출시되어 블루투스 연결을 통해 어디서나 가상자산 자산을 관리할 수 있다.

이렇듯 많은 지갑이 블록체인에서의 가상자산 관리 및 거래에 있어 중요한 역할을 하며, 웹3 생태계 내에서 지갑의 영향력은 상당하다고 평가할 수 있다. 하지만 이러한 중요성과 영향력에도 불구하고 아직 웹2 사용자들에게 진입장벽으로 느껴지는 여러 문제점들이 존재한다.

3. 불편함이 많은 기존지갑, 이유는 시드구문에 있다

3-1. 대표적인 진입장벽, 시드구문 생성 및 관리

중앙 집중식 웹2 인터넷은 소셜미디어, 인터넷 뱅킹 계정 등을 사용할 때 사용자의 이름과 아이디, 비밀번호에 의존하는 로그인 방식을 취하고 있다. 본인이 기억하기 쉬운 간단한 영문과 숫자 구성의 비밀번호 설정은 인터넷을 처음 접한 유저들이 웹2에 빠르게 온보딩할 수 있는 계기가 되어주었다. 이와 달리 웹3 사용자들은 지갑을 생성하기 위해 영문과 숫자로 된  매우 길고 복잡한 지갑 주소를 부여받고, 무작위로 주어진 12개의 시드구문를 기억해야 한다. 이를 잊어버리거나 잘못 배치했을 때는 가상자산을 영구적으로 잃을 위험에 처한다. 이러한 어려운 지갑 생성 방식은 불편한 사용자 경험을 선사함은 물론이고 웹3로의 온보딩을 크게 지체시키는 주된 요인으로 작용했다.

가상자산 지갑의 소유권 인증 및 지갑 복구를 위해 시드구문은 반드시 필요하다. 그러나, 시드구문이 유출되면 공격자에게 곧바로 악용될 수 있다. 이 때문에 추후 사용자 자신도 다시 찾아내기 어려운 방식으로 암호를 숨긴다. 특히 카카오톡과 같은 온라인상에 저장하거나, 악성 코드 감염 가능성이 있는 PC나 모바일에 사진이나 메모를 저장하는 것은 해킹의 위험성이 더욱 크기 때문에, 대부분 시드구문을 종이에 메모하여 숨겨놓는 등 아날로그적인 방식으로 보관한다. 그러나 아날로그 방식은 ‘분실’이라는 가장 근본적인 위험에 노출되어 있다. 실제로 2022년 1월, 가상자산 시장분석 업체 체인어낼리시스에 따르면, 시중에 유통 중인 1890만 비트코인 중 약 20%인 370만 개가 보유자의 암호 분실로 방치된 상태라고 한다.

3-2. 유출 시 해킹 및 탈취 위험성

사용자 자신이 시드구문을 분실하지 않아도 악의적인 공격자로 인해 유출되는 보안 이슈도 심각한 문제이다. 안랩이 발표한 ‘2023 5대 사이버보안 위협 전망’에 따르면 ‘개인 가상 지갑을 노린 공격 심화’가 포함되어 있다. 최근 대형 가상자산 거래소나 디앱 서비스의 해킹 공격에 의해 가상 자산을 거래소에서 셀프 커스터디로 옮기는 사례가 증가하였기 때문에, 그만큼 셀프 커스터디를 공격하고자 하는 시도도 증가할 것으로 예측되고 있다.


출처 :   Ahnlab, [2023 전망 1부] 안랩이 예측한 5대 사이버 보안 위협


A. PC 및 온라인상 저장되는 시드구문의 위험성

2022년 7월, 브라우저의 암호 자동완성 기능으로 메타마스크의 시드구문까지 저장되는 취약점이 발견되었다. 구문이 저장되는 시간과 경로를 해커가 파악하여 시드구문을 탈취할 수 있다는 것이 모의해킹을 통해 입증되기도 하였다. 이와 같이 PC나 온라인상에서 관리되는 시드구문은 언제나 유출의 위험에 노출되어 있다는 것을 인지해야 한다.

B. 시드구문 입력, 트랜잭션 승인을 유도하는 피싱 사이트

시드구문의 노출을 유도하기 위해 유명 지갑을 사칭하는 피싱 사이트도 존재한다. 사용자가 가장 많은 메타마스크 역시 시드구문 입력을 유도하는 피싱사이트가 생성되어 2020년부터 운영되었다. 또, 악의적인 트랜잭션을 통해 본인의 자산에 접근할 권리를 잘못 양도하도록 유도하여, 해커가 자산을 모두 탈취할 수 있도록 만든 사례도 있었다. 2022년 7월, 스캠NFT를 활용한 머니 타이거 사건이 그 일례이다.

이처럼 수탁 기관이 아닌 개인이 지갑의 모든 권한과 책임을 가질 경우, 시드구문 관리가 복잡해지기 때문에 보안 측면에서 취약할 가능성이 높다. 그렇다면 본인의 자산에 대한 권한을 온전히 가지면서도 보안 위험에 노출될 가능성을 줄일 수 있는 방법은 없을까? 이에 대해 다음 목차에서 구체적으로 알아볼 것이다.


4. 최근 주목되는 지갑 솔루션은 Smart Contract 지갑과 MPC 지갑

4-1. Smart Contract 지갑과 계정 추상화

A. SC지갑의 의미와 기능

Smart Contract(SC) 지갑은 코드 실행만 가능했던 Contract Account(CA, 계약 계정)에 Externally Owned Account(EOA, 외부 소유 계정)만 할 수 있던 트랜잭션 발행과 승인 기능을 추가한 스마트 컨트랙트 지갑이다. 개인키가 아닌 코드로 작동되며 계정 추상화(Account Abstraction, AA)라는 개념을 통해 여러 기능을 지갑에 프로그래밍 할 수 있다. 스마트 컨트랙트로 다중 서명, 소셜 복구, 전송 한도 설정 등을 프로그래밍 할 수 있어 사용성과 보안성을 높였다고 평가되고 있다.

B. 이더리움 계정 톺아보기 : EOA와 CA

먼저 모든 거래 및 계약에서 중요한 역할을 수행하는 이더리움 프로토콜의 ‘계정’에 대해 언급해 보자. 이더리움의 계정에는 개인키에 의해 작동되는 EOA와 코드에 의해 작동되는 CA로, 2가지 유형이 존재한다.

EOA는 트랜잭션을 발행하고 이를 다른 EOA나 CA에 전송하는 계정이다. 계정 주소를 통제할 수 있는 개인키가 존재하며 이를 이용해 트랜잭션을 발행하고 서명(검증)을 할 수 있다. 특이한 점은 EOA에서만 트랜잭션 검증이 가능하다는 것이다. 또한 모든 트랜잭션은 EOA에 의해서 발행되며 이 트랜잭션은 이더리움 상에서 스마트 컨트랙트를 실행시킨다.

반면 CA는 스마트 컨트랙트를 블록체인에 배포할 때 생성되는 계정이다. 내장된 코드의 논리대로 작동되며, 개인키가 없기 때문에 스스로 트랜잭션을 발행하지 못하고 EOA나 다른 컨트랙트에서 데이터를 수신해야 한다. CA는 오직 수신된 데이터(명령)에 의해서 실행될 수 있는 것이 특징이다. 이 데이터에 대한 응답으로 컨트랙트를 수행(코드를 실행)한다. 또 트랜잭션 발행과 서명의 권한이 없어 다시 EOA를 통해 서명받아야 하기 때문에 수수료를 지불해야 하는 불편함이 있다. 이처럼 트랜잭션 검증과 컨트랙트 실행으로 나뉘어 설계된 이유는 트랜잭션을 보낼 때 개인키를 공개하지 않기 위함이다.

C. 두 계정을 통합한 기술, 계정 추상화(AA)

그렇다면 개인키 보관 방식은 그대로 유지하되, CA에서도 트랜잭션 서명(검증)을 가능하게 한다면 어떨까? 이걸 가능하게 한 기술이 바로’ 계정 추상화’이다. 계정 추상화(AA)는 쉽게 말해 EOA와 CA를 하나의 계정으로 합쳐서 이용할 수 있게 한 기술이라고 할 수 있다. 계정 ‘추상화’라는 말 그대로 서로 다른 두 유형의 계정을 하나의 계정으로 추상화했다고 보면  편하다. CA에서도 트랜잭션 발행과 서명이 가능하게 하여, 계정을 한 번에 관리할 수 있는 점 등 지금까지 불가능했던 다양한 기능들을 탑재해 더욱 편리하게 지갑 계정을 사용할 수 있게 되었다.

D. AA를 구현하는 기술, ERC-4337

AA를 구현하려면 현재 이더리움 프로토콜에 하드코딩 되어있는 트랜잭션의 검증 로직을 스마트 컨트랙트로 수행할 수 있도록 변경해야 한다. EIP2938 등 계정 추상화를 구현하기 위한 많은 제안들 중 ‘ERC-4337’이 채택되었다.


ERC-4337이란 합의 계층의 프로토콜 변경 없이 AA를 구현할 수 있는 기술로, 상위 계층의 일반 트랜잭션 멤풀의 기능과 같은 'UserOperation 멤풀'을 별도로 생성하여 사용하는 방식이다. 과정을 좀 더 살펴보자면, 우선 사용자는 실행하고자 하는 트랜잭션의 데이터를 포함하는 UserOperation을 UserOperation 멤풀로 보낸다. 번들러는 이러한 UserOperation들을 하나의 트랜잭션으로 묶어 '번들 트랜잭션'을 생성한 뒤 Entry Point Contract로 전달한다. 이후 Entry Point Contract에서는 번들 트랜잭션의 각 UserOperation을 검증하고 실행한다.


즉 ERC-4337의 프로세스는, 번들러가 여러 사용자 작업을 단일 트랜잭션으로 묶은 다음, 이렇게 생성된 번들 트랜잭션을 이더리움 블록에 추가하여 Entry Point을 실행시키는 것으로 요약된다. AA를 구현할 수 있는 ERC-4337의 처리과정을 그림으로 쉽게 설명하자면 다음과 같다.



이외에도 해당 방안에는 트랜잭션 실행 비용을 지불할 수 있는 페이마스터 메커니즘과 같은 규칙들이 정의되어 있다. 결과적으로 ERC-4337 기능을 사용하면 사용자는 CA와 EOA라는 두 종류의 계정을 구별할 필요가 없어 편리한 이용이 가능하다. 실제로 현재 Stackup, Candidate처럼 ERC-4337 기반의 지갑들이 속속 출시가 되었으며, 여러 스타트업들이 이에 대한 사업성을 확인하고 관련 지갑 서비스를 개발 중에 있다.

E. 개인키 관리의 새로운 솔루션, 다중 서명(Multi-sig)

AA를 활용하면 다양한 기능을 지갑에 탑재할 수 있는데, 첫 번째로 꼽히는 기능은 바로 ‘다중  서명(Multi-sig)’이다. 현재 SC 지갑은 대부분 다중 서명 방식을 채택해 트랜잭션을 승인하고 있다. 다중 서명이란 거래 승인을 위해 미리 정해진 서명 수를 요구하는 것을 의미한다. 대부분의 다중 서명은 총 N명의 서명자(개인키)가 설정되어 있을 때, 적어도 M명(M개의 개인키)은 작업 발생 전 트랜잭션에 승인하고 서명해야 하는 M-of-N 거래를 구현한다. 이를 ‘M/N 다중 서명’이라고 하며, 이때의 M 대 N의 비율을 ‘쿼럼 지수’라고 한다. 예를 들어, 3/5 다중 서명에는 5명의 서명자가 설정되어 있고 그중 3명이 작업에 동의하거나 승인해야 한다는 뜻이다. 하나의 개인키만 노출되어도 해킹 등의 외부 공격에 의해 자산을 모두 도난당할 위험이 있던 기존의 보안 방식(단일 실패 지점)과는 달리, 트랜잭션을 실행하려면 일정 수 이상의 서명을 받아야 하기 때문에 허가되지 않은 접근을 막는다. 따라서 스캠과 같은 사기 및 해킹, 의도치 않은 송금 실수 등의 가능성을 크게 줄일 수 있다. 다중 서명 방식을 채택한 SC 지갑에서는 거래 승인을 위해 본인 외의 다수의 개인키가 필요하기 때문에, 거래소가 파산하거나 서버가 해킹돼도 자산을 지킬 수 있다. 또한 개인키가 스마트 컨트랙트에 저장되어 있어 지갑 사용자가 개인키를 보관 및 관리할 필요가 없다는 점에서 개인키 분실로 인한 보안 위험으로부터 벗어나게 된다. 이러한 특징으로, 다중 서명은 기존 지갑의 문제점으로 지적되던 개인키 보관 및 보안 문제를 해결한다.

F. AA를 활용한 기능, 송금한도, 소셜복구

이외에도 송금 한도 기능과 소셜 복구 기능도 제공한다. 지갑 사용자는 해커에 의해 지갑의 자산이 도난당하는 것을 막기 위해 전송하는 자산 액수의 한도를 설정할 수 있다. 또한 ‘소셜 복구’ 기능을 이용해 시드구문 없이도 계정 복구가 가능하다. 자신이 신뢰하는 사람의 지갑 계정 또는 하드웨어에 탑재된 지갑 계정 등을 가디언(보호자)으로 설정하여, 이 보호자가 복구를 승인하면 일정 시간이 지난 후 계정을 되찾을 수 있다(Argent 지갑의 경우, 과반수 이상의 보호자 승인을 요구하며 48시간이 지난 뒤 계정 복구가 가능함). 이는 하드웨어 지갑을 포함한 셀프 커스터디의 ‘시드구문 관리 및 보관’이라는 고질적인 문제의 해답이 될 수 있다. 소셜 복구 기능 외에도 지갑을 분실했을 때는 보호자에게 ‘지갑 잠금’을 요청하여 자산을 보호하기도 한다.

그러나 SC 지갑의 가장 큰 단점은 바로 ‘비싼 가스비’다. 스마트 컨트랙트는 온체인 상에 일일이 배포되어야 하며 이를 체인에 올리기 위해서는 가스비를 지불해야 한다. 컨트랙트를 생성하여 체인에 보관하고 실행하기 위해서는 아주 간단한 스마트 컨트랙트라도 500달러 이상 들 수 있다. 복잡한 스마트 컨트랙트를 실행할수록 EVM에서 더 복잡한 계산을 유도하고, 더 많은 가스비가 들기 때문에 높은 비용을 지불해야 한다는 단점이 있다.

G. SC사례, Safe 지갑과 Argent 지갑

Safe는 이더리움에서 가장 신뢰받는 디지털 자산관리 플랫폼이자 SC 지갑으로 웹, 브라우저, 모바일 중 사용자가 원하는 방식으로 앱 다운이 가능하다. DAO와 데스크톱 유저를 타겟으로 하며 이더리움, 폴리곤, 아발란체, 바이낸스 등의 주요 메인넷을 비롯한 모든 EVM 체인에서 지원되고 있다. 현재 23년 2월 기준 이더리움에 생성되어 있는 Safe 계정 수는 124,657개이다.  기존 SC 지갑은 비싼 가스비가 큰 단점이었지만 Safe는 유저에게 가스비를 되돌려주기 때문에 컨트랙트에 대한 수수료가 없다는 장점이 있다. 또 다중 서명의 특징을 가져 보안성 면에서도 우수하다. 현재 이더리움 전체 트랜잭션의 ~0.02%, 이더리움 가스비의 ~0.04%를 차지하며 이더리움 블록의 1~3%가량 존재한다.

Argent는 다중 서명 보안 및 소셜 복구 기능을 갖춘 SC 지갑으로 가상자산과 NFT를 보관할 수 있다. ETH, DAI, BAT, USDC 외 240개 이상의 토큰을 지원하며, iOS 및 안드로이드 스마트폰에 모바일 앱을 다운로드하여 사용할 수 있다. 일반 개인 유저와 모바일 유저, StarkNet의 ArgentX 유저를 타겟으로 하며 L1에서는 이더리움, L2에서는 zkSync와 StarkNET에서 지원되고 있다. 현재 23년 2월 기준 이더리움에 생성되어 있는 Argent 계정 수는 75,879개이다. 그리고 zkSync의 레이어 2 네트워크를 사용해 이더리움보다 훨씬 저렴한 수수료로 거의 즉각적인 거래가 가능하다. 또한 소셜 복구 기능을 통해 가디언의 승인을 받아 계정을 복구시킬 수 있기 때문에 시드구문이 필요 없고 다중 서명뿐만 아니라 생체 인식을 통해서도 지갑을 보호할 수 있다.

4-2. MPC 지갑의 단일 실패 지점 제거

A. MPC는 문제점을 어떻게 해결하는가?

MPC는 EOA 지갑과 구분되는 별개의 개념이 아닌, 기존 지갑에 적용되는 보안 기술이다. 이는 Multi Party Computation의 약어로, 자신이 가지고 있는 값은 노출시키지 않은 채로, 다수의 구성원과 데이터를 공유하여 하나의 결과 값을 연산하는 다자간 연산 기술을 말한다. 블록체인 산업에서는 다자간 서명 기술이라고도 하는데, 트랜잭션을 서명할 때 필요로 하는 개인키 하나를 다수가 부분적으로 나누어 보관한다. 서명이 필요할 경우 키를 보관하는 N명 중 지정된 비율에 따라 M명 이상이 응해야 트랜잭션을 실행할 수 있도록 설계되었다.



이렇게 키를 나눠서 보관하는 이유는 단일 실패 지점(Single Point of Failure)을 제거함으로써 보안을 강화시킬 수 있기 때문이다. 메타마스크 등 기존의 셀프 커스터디는 앞서 지적했듯이, 개인키가 유출되면 수많은 해킹 위험에 노출되고 지갑의 모든 통제권이 탈취된다는 점에 있어 단일 실패 지점을 가진다. 그러나 다수가 하나의 키를 나누어 보관하게 될 경우, 한 명의 데이터가 유출되어도 다른 사람의 데이터를 모두 알지 않는 한 자산 탈취가 불가능하기 때문에 단일 실패 지점이 제거되며 개인키 유출 및 해킹 문제를 해결할 수 있다.


MPC 기술이 적용되는 구체적인 방식은 다음과 같다. 사용자가 자신의 지갑에서 거래 가능 화이트리스트를 지정해 놓았을 때, 지갑의 개인키가 유출되고 공격자가 화이트리스트에 없는 주소로 인출을 시도한다고 가정하자. 일반 개인 지갑의 경우 모든 자산이 공격자로 인해 순식간에 탈취당하겠지만, MPC의 경우 공격자는 유출된 해당 키를 사용하더라도 부분적인 서명만 하게 된다. 네트워크 내의 다른 노드들은 해당 트랜잭션을 전달받아 오프체인 정책을 확인한 후, 해당 주소가 화이트리스트에 없다는 것을 깨닫고 자신이 가진 나머지 부분의 키를 제공하지 않는다. 이로써 서명은 완성되지 못하고 악의적인 트랜잭션은 실패하게 된다.


MPC 솔루션은 나누어진 개인 키를 하나의 온전한 키로 완성하기 위한 함수를 오프체인 상에서 실행한다. 오프체인을 사용함으로써 여러 장점이 발생하는데, 우선 데이터를 온체인에서 다루지 않는 만큼 프라이빗한 서명 체계를 가지게 된다. 또 특정한 체인이나 VM을 겨냥하여 설계되지 않기 때문에 여러 블록체인과의 호환성이 좋으며, 가스비를 발생시키지 않기 때문에 비교적 저렴하다. 이처럼 다양한 측면에서 개인키 보관 문제를 해결하며 높은 보완성을 자랑하는 MPC 기술은 가상자산을 수탁하여 관리하는 Fireblocks, Coinbase 등의 기관에서 오랫동안 보안 솔루션으로 채택되고 있다.

B. MPC Provider 사례, Fireblocks, Coinbase

Fireblocks은 가상 자산 인프라를 제공하는 기업으로, 은행과 핀테크 스타트업, 기타 금융기관을 대상으로 한다. 이들은 MPC 기술과 하드웨어 기술을 결합하여 보안성과 SLAs(Service Level Agreements)는 최대화시킴과 동시에 트랜잭션 비용은 최소화한 기업용 지갑을 제공한다. Fireblocks는 MPC-CMP라는 새로운 알고리즘을 개발하기도 하였는데, 이는 MPC 알고리즘 중 트랜잭션 서명 시간이 가장 빠르다는 특징을 가진다. 최근에는 MPC 기반의 스테이킹 기능을 추가하며 1500개의 고객 중 약 400개가 디파이 목적으로 Fireblocks 서비스를 선택하였고, 2022년 6월 기준 ARR(연간반복매출)이 1억 달러를 넘으며 현재 지갑 분야에서 상승세를 달리고 있다.


Coinbase 지갑은 Fireblocks와 달리 기관보다 거래소를 이용하는 유저들을 대상으로 한다. 일반적인 디앱에서는 소프트웨어 지갑을 사용하는 반면, 중앙화 거래소는 오프라인상에서 지갑을 관리한다. 따라서 MPC 도입 전까지는 디앱을 사용하려면 거래소의 오프라인에 보관되어 있는 자산을 셀프 커스터디를 통해 온라인으로 이동시켜야 했다. 그러나 Coinbase는 MPC 기술을 사용하면서 이러한 번거로움을 해소하였다. 이들이 제공하는 MPC 기술 기반 반수탁 지갑은 유저의 개인키를 유저와 Coinbase가 각각 일부를 나누어서 저장한다. 따라서 해킹 위험이 사라짐에 따라 온라인상에서도 자산을 보관할 수 있기 때문에, 셀프 커스터디를 거치지 않아도 거래소의 반수탁 지갑 내 자산을 곧바로 디앱에서 사용할 수 있다. 이로써 Coinbase의 반수탁 지갑은 보안성을 강화함과 동시에 고객의 시간과 가스비를 절약함으로써 디앱의 접근성을 높여준다는 의의를 가진다.


위의 두 사례처럼 중앙화된 기관이 오프체인에서 데이터베이스로 키를 보관하는 것 외에도, 탈중앙화되어 키를 관리하는 기관도 있다. 대표적으로 Lit Protocol, Entropy, Odsy 등이 있는데, 이러한 경우에는 기관이 아닌 네트워크 위의 여러 노드들이 키를 나눠서 보관한다.




이렇듯 MPC와 SC는 늘 비교선상에 세워지지만 사실 두 기술은 서로 다른 부분을 해결하고 있다. MPC는 키를 분산하여 보관하고 서명 시 공유하여 합치는 과정을 블록체인 밖에서 처리하는 오프체인 솔루션인 반면, SC는 블록체인 상의 스마트 컨트랙트 코드를 통해 키 관리를 자동화하는 온체인 방식의 솔루션이다. 두 기술은 오프체인과 온체인이라는 뚜렷하게 반대되는 지점에 놓여있기 때문에, 서로 대조되기보다는 오히려 상호보완적 관계이다. 따라서 이는 두 기술의 장점을 모두 갖출 수 있는 SC와 MPC의 혼합 솔루션으로 이어질 수 있다. MPC는 더 보안성이 강화된 개인 키 관리를 제공할 수 있고, 동시에 SC 기술을 사용하여 확장성을 추구할 수 있게 된다. 현재까지는 최근에 대두된 분야인 만큼 기술적인 한계 때문에 결합되지 않고 있지만, 시간이 흘러 기술적인 조건이 충족된다면 두 기술은 상호보완적으로 결합되어 시너지를 발생시킬 수 있을 것이다.

5. 미래의 웹3 생태계를 이끌 차세대 지갑 비즈니스

기존 지갑 비즈니스 모델은 가상자산 보관 및 관리에 그쳤지만, 가까운 미래에는 신생 기술을 활용한 다양한 사업으로 변모할 것으로 보인다. 이번 목차에선 지갑의 새로운 비즈니스를 제시하고, 지갑에서 확장된 비즈니스와 핀테크 서비스에서 착안한 지갑의 슈퍼앱 가능성에 대해 고찰해보고자 한다.

5-1. 지갑 확장 비즈니스

A. 자유로운 수수료 결제 수단 및 자동결제 시스템 활성화

AA를 활용하면 더욱 편리한 수수료 지불 서비스를 구현할 수 있다. 이더리움의 ERC-4337에서는 Entry Point Contract로 해당 플랫폼 또는 프로젝트가 사용자 대신 가스비를 지불하는 Paymaster기능을 지원한다. 현재 이더리움 수수료가 타 체인에 비해 높은 편이기 때문에 이 같은 기능의 도입은 사용자 경험을 일정 부분 개선할 수 있다. 또한 토큰의 종류에 상관없이 수수료를 지불할 수 있다. 이더리움과 타 블록체인들의 공통점은 지정된 자체 토큰으로 가스비 지불을 요구한다는 것이다. 즉, 소유하고 있는 토큰을 해당 토큰으로 스왑 하는 과정에서도 수수료가 발생하며, 사용자가 추가적으로 지불해야 하는 비용의 증가를 초래한다. 그러나 AA를 사용하면 지정된 토큰이 아닌 ERC-20 토큰이나 사용자 본인이 원하는 토큰으로 가스비를 낼 수 있다. 만약 신용카드로 거래 수수료를 지불하는 기존의 지갑 서비스와 접목된다면 토큰뿐 아니라 실물 신용/직불카드로 가스비를 낼 수 있을지도 모른다. 이처럼 토큰이나 지갑의 뚜렷한 부각 없이 가스비를 지불할 수 있는 시스템의 출현으로 Seamless 한 지갑 서비스가 가능해질 것이다.

AA를 사용하면 사용자의 가상자산 지갑에서 전기요금이나 전화요금을 내는 자동결제 시스템도 가능해진다. 이 자동결제 시스템이 갖춰지면 현재 우리가 모바일 뱅킹에서 쉽게 하고 있는 OTT 정기결제나 청구서 요금 납부 등을 인터넷 접속 없이도 할 수 있다. 실제로 작년 12월 VISA 카드에서 AA를 사용한 자동결제 서비스 도입을 발표한 바 있다. 다만, 모든 이더리움이 AA를 구현하지 않았다는 한계점을 감안하여 L2 스타크넷을 활용하겠다는 입장이다. 현재의 자동결제 서비스는 일반 은행 계좌에서 쉽게 설정할 수 있지만 궁극적으로 중앙화된 시스템을 거쳐야 한다. 하지만 AA를 통한 자동 결제 시스템은 중앙화된 은행을 거치지 않고, 사용자와 플랫폼을 직접적으로 연결해 ‘탈중앙성’이라는 블록체인의 본질적 가치를 구현한다.

B. 자체 토큰 발행 및 지갑의 탈중앙화

더불어 자산 관리라는 지갑의 본질적 기능 외에도, 지갑 내에 자체적인 토큰을 발행하는 방향도 있다. 대부분의 디파이 서비스는 토큰 발행을 기본적으로 하고 있거나 NFT 마켓 운영으로 수수료를 가져가는 방식을 취하고 있는데, 이와 마찬가지로 지갑 사업에서 자체 토큰을 발행한다면 어떤 긍정적인 결과를 불러올 수 있을까?

우선 개인지갑의 수수료 문제 해결에 일조할 수 있다. 개인지갑은 트랜잭션 과부하로 수수료 값이 급격하게 오르는 등 수수료의 변동성이 매우 크다는 치명적 단점 때문에 가상자산 사업자조차 사용을 꺼리는 경향이 있다. 그러나 지갑이 자체 토큰을 발행하게 되면, 토큰 홀더들에게 거래 수수료를 감면해 주는 혜택을 제공할 수 있다. 즉, 사용자 입장에선 거래 수수료 비용을 상당 부분 아낄 수 있는 기회이기에 지갑 서비스를 계속해서 사용하는 하나의 요인로서 작용할 것이다. 또한 비즈니스적 관점에서 볼 때, 지갑의 토큰 발행 기능을 활용한 포인트 통합 서비스도 가능해진다. 지갑이 다른 기업과 제휴를 맺음으로써 해당 기업들의 포인트를 지갑 내 자체 토큰으로 변환할 수 있다. 또한 지갑의 자체 토큰을 다른 제휴처의 포인트로 변환하는 것도 가능하므로, 사용자는 뿔뿔이 분산되어 있는 적립 포인트를 통합적으로 이용할 수 있게 된다.

더 나아가 토큰의 의결권 행사를 통해 ‘지갑의 DAO화’를 기대해 볼 수 있다. 발행된 자체 토큰이 거버넌스 토큰으로 기능한다면, 사용자에게 조직 내의 의사결정에 참여할 수 있는 일종의 투표권을 부여하면서 커뮤니티 형성 및 활성화에 중요한 역할을 한다. 해당 거버넌스 토큰 보유자만이 제안과 투표 참여가 가능하기에 사람들은 의결권 행사를 위해 토큰을 얻고자 노력할 것이고, 결과적으로 이는 지갑의 활발한 사용을 불러올 수 있다. 이렇듯 지갑이 DAO화 되면 DAO 내 구성원들끼리 하나의 개인키를 나눠 소유하는 방식으로 MPC 기술을 적용시키는 것도 가능하다. 이와 같이 자체 토큰 발행 기능이 지갑에 도입된다면 지갑 사용성 증대처럼 다양한 기대효과를 예상해볼 수 있다.

C. 지갑 내 탑재된 투자자문 서비스: 지갑 사업 타겟층 확장

기존의 금융시장에서 조명받고 있는 기술 중 하나는 ‘로보어드바이저(Robo-Advisor)’이다. 로보어드바이저란, 인공지능을 활용한 데이터 마이닝을 통해 고객에게 맞춤형 투자 포트폴리오를 추천해주는 프로그램을 말한다. 기존의 인간의 업무를 대체해 짜여진 알고리즘을 통해 실행함으로써 실수나 악용의 확률을 줄이며 객관적인 추천이 가능하다.

가상자산 지갑에 로보어드바이저를 도입시킬 경우, 별도의 고객 데이터를 제공받지 않아도 알고리즘에 필요한 정보를 수집할 수 있다. 보유한 자산의 종류, 홀딩 기간, 거래 빈도수, 트레이딩 성향 등 모든 데이터가 블록체인에 투명하게 공개되어 있기 때문에, 이를 수집하고 분석하는 과정이 간소화된다. 따라서 자산과 거래 내역 기반의 로보어드바이저 기능을 도입한 지갑은 새로운 지갑 사업 아이템으로서 활약할 수 있을 것이다. 또한 투자자는 로보어드바이저 기능을 사용하기 위해 기존 거래에서는 필요없던 웹3 지갑을 새롭게 생성해야 하므로 해당 기술은 지갑 사용자 유입의 한 요소가 된다.

5-2. 핀테크 서비스로 본 웹3 지갑의 슈퍼앱 발전 가능성

국내의 대표적인 핀테크 앱인 토스와 뱅크샐러드는 금융 기능 외에 다양한 기능을 추가하여 서비스를 확장하였다. 토스는 만보기, 채팅, 오늘의 머니팁, 주식 등의 기능이 있고, 뱅크샐러드는 유전자 검사, 습관 만들기, 은퇴 설계하기 등의 기능을 갖추고 있다. 특히 토스는 2022년 6월 기준 MAU 1,427만 명을 기록하는 등 독보적인 금융 플랫폼 MAU 1위를 달성하며 서비스 확장을 통한 슈퍼앱 전략에 성공하였다.

그렇다면 웹3 지갑은 슈퍼앱으로의 발전 가능성이 있을까? 토스와 뱅크샐러드처럼 금융 외의 다양한 서비스를 하나의 지갑에서 손쉽게 관리하기 위한 시도들이 Web3 생태계에서도 일어나고 있는데, 대표적으로 Backpack사에서 개발 중인 ‘xNFT’가 있다. xNFT란 실행가능한 코드가 담겨있는 NFT를 의미한다. 즉 디앱을 토큰으로 발행하는 것이 실현 가능하다는 의미이고 이는 다양한 서비스를 지갑 속에 내장하는 것이 가능하다는 것을 입증한다. 지갑이 일종의 앱스토어가 되고, 그 안에 담긴 xNFT 형태의 애플리케이션들을 지갑 내에서 자유롭게 실행시킬 수 있는 것이다. 따라서 웹3 지갑도 웹2 핀테크 서비스와 같이 다양한 서비스를 제공하는 디앱들을 지갑에 담을 수 있으며, 토스와 같이 슈퍼앱으로까지 발전할 가능성이 충분하다.

가상자산 지갑은 웹3 슈퍼앱을 넘어 웹2 영역까지 활용 범위를 확장할 수 있다. 예로, 모바일 신분증, 공인 인증서, 국가 인증 자격증 등 개인인증과 관련된 문서를 토큰화하여 하나의 지갑에서 관리한다면, 일상 속 모든 인증이 편리해질 것이다. 또한, 이렇게 지갑에 토큰화된 모바일 신분증을 보유한다면 연말정산 등 공공웹사이트에서의 민원처리 과정이 훨씬 간소화될 수 있을 것으로 기대된다. 이러한 움직임은 지갑 사업자가 본인인증과 자격증명을 요하는 여러 기업, 기관 등과 제휴를 맺는 것에서부터 시작될 것이다.


그러나, 국내에서는 웹2에 비해 웹3 지갑의 슈퍼앱을 향하는 행보가 잘 보이지 않는데, 전반적으로 웹3 지갑 사업이 확장하기 어려운 이유 중 하나는 한국의 ‘포지티브’ 규제이다. 외국은 대부분 ‘네거티브’ 규제이기 때문에 제한 범위 밖의 모든 영역을 다룰 수 있지만, 국내의 경우 규제에서 허가하는 범위 내에서만 사업 운영이 가능하고 그 외로 확장할 수 없다. 일례로, 위의 장표와 같이 다양한 DeFi 사업을 국내에서 운용하기 위해선 VASP 인가를 등록해야 한다. 이를 위해 사업자는 ‘실명계정 발급, 자금세탁방지시스템 구축, 정보보호관리체계(ISMS)를 인증 및 획득해야 한다는 정해진 법의 테두리 안에서만 사업을 진행할 수 있다. 이처럼 다양한 서비스를 지갑에 도입하는 것은 현 상황에서 다소 어려운 것으로 보인다. 따라서 슈퍼앱으로서의 발전 가능성이 충분한 웹3 지갑이 더 다양한 영역으로 서비스를 확장하기 위해서는 가장 먼저 규제의 완화가 따라야 한다.

6. 지갑 시장 활성화를 가로막는 허들은 바로 규제

6-1. 국내 지갑 관련 규제인 KYC, 트래블룰

A. KYC와 트래블룰이란?

가상자산 거래 보관 및 관리 서비스를 제공하는 지갑 사업자들은 모두 가상자산사업자(VASP)로 분류된다. VASP는 가상자산이 자금 세탁 범죄로 사용되는 것을 방지하기 위해 국내 고객확인인증(일명 KYC) 내용이 담긴 개정 특정금융정보이용법(이하 특금법)에 규정된 고객확인의무를 준수해야 한다. 이에 따라 VASP는 사용자사용자에 대한 개인 식별 정보를 수집해야 하며, 공식 데이터베이스에서 해당 정보가 확인될 필요가 있다. 또한 KYC는 서류 등으로 개인을 특정할 수 있는 정보를 확인하는 신원 확인, 이를 진행하는 사람이 정말 본인이 맞는 지 확인하는 본인 인증, 이렇게 두 가지 과정으로 보통 구성된다. 사용자는 이러한 프로세스를 통해 본인의 이름, 주소, 생년월일 같은 개인정보를 제공해 가입할 수 있다. VASP는 이러한 정보를 사용해 사용자의 신원 확인을 하고 사용자의 정보의 정확성과 최신 상태임을 확인해야 한다.

다음으로 국내 트래블룰(자금이동추적규칙) 규제에 대해 알아보자. 트래블룰은 VASP가 가상자산을 송수신할 때 송수신자의 정보를 확인하는 절차를 거치도록 하는 국제자금세탁방지기구(FATF)의 규정이다. 국내 특금법 개정안에 관련 규정이 포함되어 ‘코인 실명제’ 제도라는 이름으로 시행된 이후, 국내 거래소들은 거래소간 혹은 개인지갑으로 거래 시 신원인증이 완료된 곳으로만 전송이 가능하다. 그러나 국내 VASP는 개인정보보호법에 따라 사용자의 정보를 타사와 공유하는 것이 불가능하기 때문에 트래블룰을 준수하기가 어려운 상황이다.

B. KYC와 트래블룰은 지갑사업에 왜 문제가 되는가?

다음으로는 여러 규제들 중  KYC와 트래블룰 규제가 지갑 사업에 있어 특히 문제가 되는 이유에 대해 간략하게 다뤄보겠다. 먼저 가상자산사업가가 지속적으로 고객을 온보딩하고 사업을 진행하기 위해선 반드시 KYC 정책/지침을 이해하는 것이 중요하다. 또한 KYC 준수에 대한 준비를 사전에 해둠으로써, KYC와 관련된 잠재적인 법적 이슈나 규제 위반으로부터 지갑 회사와 고객 모두를 보호할 수 있다. 트래블룰 역시 국내 지갑 사업에 매우 중대한 영향을 미친다. 트래블룰 시행에 대한 대응으로 코인 거래소들은 트래블룰 관련 솔루션을 연동하고 입출금이 가능한 외부 지갑 주소에 대한 가이드라인을 만들어왔다. 특히 최근 NFT와 디파이에 대한 관심이 증가하면서 메타마스크 등 외부의 개인 지갑에 대한 수요가 늘어났기 때문에, 어떤 외부 지갑 주소로 입출금이 가능한지가 사용자 입장에선 중요한 사항일 것이다.

그러나 FATF나 금융당국에서 제시된 트래블룰 가이드라인이 아직까지 부재하기 때문에 거래소마다 이용방법이 다르다는 문제가 있었다. 현재는 국내 거래소별 화이트리스트를 통해 사전 등록한 지갑 주소에 대해선 입출금이 가능하지만 외부 개인 지갑 등록은 당분간 어려울 것으로 생각한다. 즉 트래블룰 시행으로 개인정보 확인이 어려운 개인지갑의 사용 제한이라는 결과가 발생하는 것이다. 이는 지갑 시장 내에서 거래 활성화를 막고 개인지갑의 신규 이용자 유입이 적어지게 만들어, 가상자산 사업가 입장에서도 지갑 사업의 확장 및 성장에 있어서 걸림돌이 될 수밖에 없다.

C. 메타마스크처럼 탈중앙화를 지향하는 지갑 같은 경우 어떻게 대응하는가?

앞서 우리는 VASP가 특금법의 ‘고객 확인의무’에 따라 이용자를 대상으로 한 KYC 프로세스를 도입해야 한다는 것을 확인하였다. 그러나 개인 식별 정보를 요구하지 않는 메타마스크, 마이이더 월렛과 같은 탈중앙화된 비수탁형 지갑은 KYC를 따르지 않는다.  트래블룰 시행 이후 개인 지갑 사용만으로는 거래소 이용이 불가능하기 때문에 이에 대한 대응 방법으로 본인 소유의 지갑임을 인증받은 계정끼리만 거래하도록 하는 화이트리스트 등이 거론된다. 지금까지 KYC를 지원하지 않던 메타마스크도 국적, 신분증 번호, 출생지, 신원을 확인할 수 있는 신분증 같은 정보를 요구하도록 개인정보보호정책을 개편하면서 KYC 제도를 준수하려는 움직임을 보이고 있다.

6-2. 국내 지갑 Klip, Dosi의 규제 대응 현황

그렇다면 국내의 가상자산 개인 지갑들은 이러한 규제에 대해 어떻게 대응하고 있을까? SNS 계정 연동을 통해 지갑을 생성하는 카카오톡의 Klip 지갑과 라인의 Dosi 지갑이 그 예시이다. Klip 지갑은 계정을 생성하기 위해 카카오톡 계정을 연동해야 한다. 이 과정에서 실명, 휴대전화 번호, 이메일 주소 등 기존 카카오톡 계정에 담겨있던 개인 정보가 전달되기 때문에 Klip 지갑에도 고객의 신원 정보가 담기게 된다. Dosi 지갑 역시 계정을 생성하려면 라인, 페이스북, 구글, 네이버 중 하나의 계정을 연결해야 한다. 이후 정보 제공 동의를 거쳐 6자리의 패스 코드를 설정하면 지갑 생성이 완료됨과 동시에 Citizen NFT라는 가입 환영 NFT가 지급된다. 따라서 Dosi 지갑과 연동한 SNS 계정으로부터 제공된 신원 정보로 KYC를 준수하고 있다.

이와 같이 SNS 계정을 연결하여 신원 정보를 전달하는 방식을 채택하지 않는 개인 지갑들은 어떻게 고객에게 신원 인증을 받을 수 있을까? 모든 지갑들이 KYC 준수 솔루션을 마련하기는 쉽지 않은데, VASP는 보통 스타트업 혹은 중소기업의 형태로 시작하기 때문에 비대면 신원 인증과 같은 기능을 구현하는 데에 요구되는 기획, 디자인, 개발 과정이 부담이 될 수 있다. 또 국내외 모두 개인 지갑에 대한 규제의 방향성이 아직까지도 뚜렷하게 나오지 않았기 때문에, KYC 등의 체계를 갖출 필요성을 크게 느끼지 못할 수 있다. 특히 메타마스크와 같이 매우 오랫동안 지갑 생태계의 점유율을 장악해온 서비스의 경우, 가상자산 생태계의 가치관을 신경쓰지 않을 수 없는데, 정보 수집에 대한 커뮤니티의 부정적인 여론도 간과할 수 없을 것이다. 이러한 여러가지 이유로 신원 인증 과정을 갖추지 않은 개인 지갑들이 KYC 규제라는 허들로 인해 거래소 출금이 막히는 등의 불이익을 겪지 않을 수 있는 대안은 무엇이 있을까?

6-3. 웁살라 시큐리티 등 신흥 솔루션 제시

대표적인 해결방안의 사례로는 블록체인 보안 업체인 웁살라 시큐리티가 2022년 1월에 출시한 ‘컴패스 프로토콜’이 있다. 컴패스 프로토콜이란 KYC/AML 시행 후 신원 인증 NFT를 지급하는 방식의 웹3.0 전용 신원 인증 플랫폼이다. 앞서 언급한 바와 같이 트래블룰이 시행됨에 따라 국내 거래소들은 개인지갑으로 거래 시, 신원 확인이 가능한 개인 지갑으로만 자산 전송이 가능하다. 이에 따라 중앙화 거래소를 이용하는 이용자들은 컴패스 프로토콜을 통해 KYC/AML 정보를 제공하여 인증 절차를 마치면 고유한 신원 증명 NFT를 발급받을 수 있다.


이러한 NFT의 활용으로 지갑에 신원 증명서를 항시 보유하는 것이 가능해졌다. 이로 인해 실명 인증 없이 계좌만 생성하여 거래할 경우 발생할 수 있는 범죄 등으로 인한 피해가 적어진다. 또 NFT를 보유하다가 필요시 상황에 맞게 선택적으로 본인인증에 활용할 수 있기 때문에 규제에 대응하며 블록체인 서비스를 유연하게 사용할 수 있도록 돕는다.

컴패스 프로토콜은 가상자산 지갑을 연동하여 자금 세탁에 연루된 지갑과의 연관성 및 이상행위 여부를 검증하는 AML, 성명, 이메일 주소 등을 입력하여 고객의 신원을 인증하는 KYC, 마지막 NFT 인증서 발행이라는 프로세스에 따라 비교적 쉽고 간편하게 발급받아 사용할 수 있다는 강점을 가진다. KYC 인증뿐만 아니라 AML 인증 절차도 거치기 때문에 신원 증명 외에도 웹3 생태계 전반에서 다양한 증명서로 이용할 수 있으며, 신원 도용 및 금융 사기와 같은 범죄 발생을 막기 위한 대안이 될 수 있기 때문에 이러한 솔루션의 필요성이 점점 증대되고 있다.

이 외에도 많은 VASP가 기능 구현에 있어서 특히 부담을 느끼는 eKYC(비대면 실명 확인 인증)를 대신 구현해서 API 형태로 솔루션을 제공하는 useB와 같은 기업들도 있다. 이와 같이 규제로 인해 발생하는 한계점을 해결하기 위한 ‘레그테크(Reg-Tech) 스타트업’이 많이 생겨나며 가상자산과 관련된 국내 규제에 대한 대응 방안은 계속해서 발전하고 있다.

7. 맺으며

우리는 현재 블록체인 기술이 대중화되기 전 과도기에 놓여있다. 그동안 큰 장벽으로 여겨진 '시드구문' 문제점을 해결하기 위한 일환으로 SC, MPC 솔루션을 살펴봄으로써 대중화 가능성을 엿볼 수 있었다. 또한 앞서 제시한 자동결제, 자체 토큰 발행을 통한 DAO 시스템 구축 등 새로운 형태의 지갑 비즈니스들을 구상해 볼 수 있다. 지갑 시장은 플랫폼 사업까지 서비스를 확장되어 웹3 내의 슈퍼앱으로 성장할 수 있는 잠재력을 갖추고 있다. 이와 같이 지갑 서비스들이 강화됨으로써, 웹2에서 웹3로의 온보딩을 돕는 역할로 자리 잡을 수 있다. 따라서 지갑이 블록체인의 대중화 시기를 더욱 앞당길 수 있는 하나의 촉매제로  작용하길 기대해 본다.



본 글에 기재된 내용들은 작성자 본인의 의견을 정확하게 반영하고 있으며 외부의 부당한 압력이나 간섭 없이 작성되었음을 확인합니다. 작성된 내용은 작성자 본인의 견해이며, (주)크로스앵글의 공식 입장이나 의견을 대변하지 않습니다. 본 웹사이트를 통해 제공되는 정보는 투자 자문이나 권유에 해당하지 않습니다. 별도로 명시되지 않은 경우, 투자 및 투자전략, 또는 기타 상품이나 서비스 사용에 대한 결정 및 책임은 사용자에게 있으며 투자 목적, 개인적 상황, 재정적 상황을 고려하여 투자 결정은 사용자 본인이 직접 해야 합니다. 보다 자세한 내용은 금융관련 전문가를 통해 확인하십시오. 과거 수익률이나 전망이 반드시 미래의 수익률을 보장하지 않습니다.



Drops7: Megaton Finance — ‘oMEGA’

We are proud to announce the 7th Drops with ‘oMEGA’ of Megaton Finance!

1. oMEGA Drops information

  • Total Tokens: 100,000 oMEGA
  • Snapshot duration: Feb 14th ~ Feb 20th, 2023 (7 days)
  • Claim date: 00:00 a.m (UTC), Feb 23th, 2023

Drops is a Meshswap platform that enables various Polygon-based projects to effectively distribute their initial token resources and successfully perform the entire process from distribution, implementation, and liquidity activation plan. Only MESH stakers are eligible for new token project airdrops.

2. How to participate

Exclusive for MESH Stakers. Stake MESH to earn oMEGA tokens.

The airdrop will be distributed based on the snapshot of the vMESH amount held by users after MESH staking, and the snapshot will be held once a day at 00:00 AM (UTC). To receive the airdrop, users must have staked MESH and obtained vMESH before the snapshot.

① Go to the “Staking and voting” section on Meshswap and stake MESH.

Link to stake MESH:

② Users can check the expected amount of airdrops in the Upcoming status Drop card. (*)

③ The airdrop quantity is determined according to users’ vMESH stake at the time of one snapshot every day.

④ Users can claim the final airdrop quantity with their wallet on the claim date.

(*) Drops under “Upcoming” status, “My Airdrop Amount” is a real-time estimation of how much users will be receiving.

The actual amount received will be based on snapshots that occur every 00:00 am (UTC)

How to Stake MESH

3.. Megaton Finance & MEGA

About Megaton Finance

Megaton Finance is the first autonomous financial protocol within the TON network that provides yield farming opportunities such as swaps and pair deposits. Megaton Finance has a structure that combines the AMM (Automated Market Maker) DEX business model prevalent in the DeFi ecosystem, the scalable multi-chain economy, and the unique characteristics of the TON network.

About MEGA

MEGA is a governance token that maintains the ecosystem of Megaton Finance, and the initial quantity issued through inflation is provided to LP (Liquidity Provider). When the staking function is added to Megaton Finance, MEGA staking participants will receive MEGA as a reward. Total supply of MEGA is 100,000,000 MEGA. Community LP is 54,000,000 MEGA(54% of the total supply) and has a halving period(every 4 years).

MEGA Token Allocation

1. Total Supply: 100,000,000 MEGA

2. Token Distribution

  • Community LP 54%
  • Developer 16%
  • Investor 7%
  • Advisory 5%
  • Marketing 5%
  • Partnership 5%
  • Liquidity 4%
  • Reserve 3%
  • Initial Supply 1%

3. Initial Supply: 1,000,000 MEGA

To build the initial Megaton Finance ecosystem, 1,000,000 MEGA (1% of total supply) will be utilized for marketing, MEGA LP incentives, and Tonstarter.

Megaton Finance will create a stable trading environment by securing potential users and liquidity on the TON network through the events using initial supply.

4. Halving

  • Inflation is equal to 1/2 of the previous year’s inflation every 4 year

5. Distribution quantity per block

  • 0.217013889 MEGA/block ,18,750 MEGA/day (based on first-year distribution)
  • TON block time = 5 seconds

Learn more about MEGA tokens

Megaton Finance

Official Website:


Telegram (ANN):

Telegram (Global):

Telegram (Korean):



메가톤 파이낸스에서 위믹스 페어에 예치하는 방법


  1. 메가톤 파이낸스(에 접속 후 [Connect Wallet] 버튼을 눌러 원하는 톤 지원 지갑을 연결해주세요.


2. 톤 지원 지갑을 성공적으로 연결 후 [Deposit] 탭을 눌러주세요.


3. 이벤트 *대상 페어 중 원하는 페어를 선택 후 오른쪽의 [Manage] 버튼을 눌러주세요.
* 대상 페어: oUSDC-oWEMIX$ / oWEMIX-oWEMIX$


4. 예치하려는 정보가 맞는지 확인 후 [Continue] 버튼을 눌러주세요.


5. 예치하려는 페어 중 한 쪽 토큰에 예치할 수량을 입력하면 나머지 토큰의 예치 수량도 이미 예치한 토큰 수량의 비율에 따라 자동으로 입력됩니다. 이후 [Deposit] 버튼을 눌러주세요.


6. 선택한 페어 중 [Deposite Token A]를 선택해 주세요.


7. 연결한 톤 지원 지갑에 [Token A]에 대한 트랜잭션 확정 팝업(Confirm Transaction)이 표시되면 내용 확인 후 [SEND TON] 버튼을 눌러주세요.


8. [Password] 미니 팝업에 비밀번호 입력 후 [NEXT] 버튼을 눌러주세요.


9. 첫 번째 토큰 예치가 완료되면 [Done!] 메시지가 새로운 미니 팝업에 표시됩니다. 미니 팝업에서 [CLOSE] 버튼을 눌러주세요.


10. Tonken A와 동일하게 선택한 페어 중 [Deposite Token B] 버튼을 눌러주세요.


11. [Token B]에 대한 Confirmation 미니 팝업이 표시되면 내용 확인 후 [SEND TON] 버튼을 눌러주세요.


12. [Password] 미니 팝업에서 비밀번호 입력 후 [NEXT] 버튼을 눌러주세요.


13. 두 번째 토큰 예치가 완료되면 [Done!] 메시지가 미니 팝업에 표시됩니다. 미니 팝업에서 [CLOSE] 버튼을 눌러주세요.


14. [Deposit] 화면 상단의 [My deposit]에서 내가 예치한 페어의 현황을 확인할 수 있습니다.



안녕하세요 메가톤 파이낸스 커뮤니티 여러분 !


2023년 1월 30일, 메가톤 파이낸스가 톤(TON, Telegram Open Network) 블록체인에서 정식 출시했습니다.


메가톤 파이낸스는 AMM 기반 DEX로 톤 디파이 사용자들에게 다양한 금융 기회를 제공할 예정입니다.


자세한 사항은 아래 내용을 확인해주시기 바랍니다 .


■ 목차

1. TON (The Open Network)

2. 메가톤 파이낸스 소개

3. 오르빗 브릿지: 밸리데이터

4. CertiK 오딧

5. MEGA: 거버넌스 토큰

6. MEGA 토크노믹스


1. TON (The Open Network)


톤(TON, The Open Network)은 수십억 명의 사용자를 온보딩하기 위해 텔레그램이 설계한 탈중앙 레이어 1 블록체인입니다. 월 활성 사용자 수(MAU)가 7억명에 달하는 글로벌 메신저인 텔레그램에서 추진한 프로젝트로, 추후 오픈 소스로 전환되면서 개발자 커뮤니티에 의해 발전하고 있습니다. 최근 텔레그램 내 지갑 기능 업데이트로 톤 블록체인의 네이티브 토큰인 톤코인(Toncoin)의 활용도 또한 증가하는 추세입니다.


2022년 기준, 톤 블록체인은 진정한 확장성을 갖춘 몇 안 되는 블록체인 프로젝트 중 하나로 남아 있습니다. 여전히 수백만 건을 수행할 수 있는 가장 진보된 블록체인 프로젝트이며, 향후 필요시 초당 수천만 건의 진정한 튜링 완전 스마트 컨트랙트 트랜잭션을 수행할 수 있습니다.


톤은 출범 이후 5년간 놀라울 정도로 진화해왔고, 여전히 범용 블록체인 기술의 최첨단을 달리고 있습니다. 2017년부터 톤 백서에서 제안한 아키텍처 접근 방식의 효율성은 지난 몇 년 동안 개발된 톤 기술 구현을 기반으로 한 다양한 테스트넷 및 메인넷의 입증된 고성능으로 더욱 검증됐습니다. 톤 공식 홈페이지의 블록체인 분석에 따르면 설계 및 구현 측면에서 이더리움과 솔라나보다 우위에 있으며, 개발자와 커뮤니티의 높은 기대치를 충족할 수 있는 궁극적 해결책이 될 수 있다고 합니다.


톤의 특별함은 블록체인 그 자체에만 있지 않습니다. 무엇보다 톤은 7억명의 MAU를 자랑하는 텔레그램 메신저와 다양하게 결합할 수 있다는 잠재력이 있습니다. 이는 타 블록체인에서 찾아볼 수 없는 특별함으로, 이미 톤 생태계는 수백개에 달하는 챗봇 & 웹앱(지갑, 브릿지, 마이닝, 채널, 챗, 소셜 네트워킹, 겜블링 등) 기반을 갖추고 있습니다.


2. 메가톤 파이낸스


메가톤 파이낸스는 오지스가 개발한 탈중앙화 거래소 프로토콜로 참여자들에게 스왑, 이자 농사(Yield Farming) 등의 금융 기회를 제공합니다. 사용자는 메가톤 파이낸스에 유동성을 공급하고 거래 수수료 및 MEGA 토큰을 보상으로 얻을 수 있습니다. MEGA 토큰 마이닝은 2월 23일 오전 9시(KST)에 시작될 예정입니다.


출시 시점 기준, 메가톤 파이낸스는 유니스왑 V1과 같이 페어와 페어를 연결하는 라우팅 기능이 없습니다. 모든 페어는 WTON을 기반으로 생성되며 토큰을 스왑하려면 2번의 스왑 과정을 거칩니다. 가령 A 코인을 B 코인으로 스왑 시 WTON/A 페어에서 A 코인을 WTON으로 변환한 뒤 WTON을 다시 활용하면 WTON/B 페어에서 B 코인으로 스왑할 수 있습니다. 추후 톤 블록체인 업그레이드 시 유니스왑 V2와 같은 라우팅 기능 활용 및 즉각적인 스왑 기능을 구현하고자 합니다.


또한, 메가톤 파이낸스를 단일/플러스 예치, 레버리지 파밍 등 다양한 금융 상품을 탑재한 프로토콜로 발전시켜 나갈 것입니다. 사용자는 톤 생태계 내의 자산을 다양한 방법으로 활용해 수익 창출 기회를 얻을 수 있습니다.


궁극적으로 메가톤 파이낸스는 오지스가 개발할 예정인 텔레그램 챗봇 기능을 극대화해 사용자 경험을 크게 개선할 계획입니다. 이를 통해 기존 디파이 사용자뿐 아니라 7억명의 텔레그램 사용자를 모두 수용할 수 있는 사용자 친화적인 디파이 프로토콜이 되겠습니다.


3. 오르빗 브릿지


메가톤 파이낸스는 오지스가 개발한 글로벌 탑 7 브릿지인 오르빗 브릿지를 활용해 톤 생태계를 확장하고자 합니다. 오르빗 브릿지는 80만건 이상의 트랜잭션, 120억 달러를 상회하는 총거래량, 2억 달러 이상의 TVL을 기록하면서도 단 한 번의 해킹 사고가 나지 않은 견고한 크로스체인 브릿지입니다. 오르빗 브릿지는 현재 Ethereum, Klaytn, BNB, HECO, Stack, Ripple 등 19개의 다양한 네트워크와 ETH, USDT, USDC 등 86개 이상의 자산을 지원하고 있습니다.


오르빗 브릿지는 Trustless, Secure Multiple-Signature Verification으로 오지스, Ground X, DSRV 등 분권화된 주체가 온체인에서 합의를 달성하는 탈중앙 시스템과 스마트 컨트랙트 기반의 빠른 합의 프로세스를 구축했습니다. 메가톤 파이낸스는 안정적이면서도 확장성이 높은 오르빗 브릿지를 통해 Ethereum을 비롯한 다양한 네트워크에 있는 BTC, ETH, USDT, USDC, MATIC 등 주요 자산 활용 기회를 제공합니다.


메가톤 파이낸스는 오르빗 브릿지를 통해 다양한 메인넷의 자산을 톤 생태계 안으로 유입할 것입니다. 수많은 프로젝트는 톤 생태계를 통해 그들의 블록체인, 프로토콜, 토큰 등을 자연스럽게 홍보할 수 있으며, 더 많은 사용자를 지지자로 만들 수 있습니다. 오르빗 브릿지는 이들 모두를 잇는 연결 고리로서, 메가톤 파이낸스와 함께 성장할 것입니다.


4. CertiK 보안 감사


메가톤 파이낸스는 톤 생태계의 대표적인 탈중앙화 금융 프로토콜로 거듭나기 위해 프로토콜의 안전성을 우선순위에 놓았습니다. 다양한 자산이 예치될 메가톤 파이낸스 컨트랙트의 위험 요소를 최소화하고자, 세계적인 블록체인 보안 기업인 CertiK에서 보안 감사를 받았습니다. CertiK에서 진행한 보안 감사 결과 및 요약 내용은 아래를 확인바랍니다. 앞으로도 정기적인 보안 감사 진행으로 사용자가 안심하고 메가톤 파이낸스를 사용할 수 있도록 노력하겠습니다.


CertiK 보안 감사 리포트





메가톤 파이낸스는 비신뢰 기반 탈중앙화 프로토콜로 특정 운영자가 아닌 거버넌스에 의해 프로토콜과 관련된 모든 사항을 결정합니다. 따라서 메가톤 파이낸스는 거버넌스를 통해 정책과 방향성이 결정될 수 있도록 거버넌스 토큰 ‘MEGA’를 발행했습니다.


MEGA는 유동성 마이닝, 스왑, 거래소(CEX, DEX) 등에서 획득할 수 있으며, 총 발행량은 100,000,000 MEGA입니다. 초기 공급량은 전체 발행량의 1%이며, MEGA의 구체적인 토크노믹스는 다음과 같습니다.


6. MEGA 토크노믹스

1) 총 발행량: 100,000,000 MEGA

2) 블록당 분배 수량: 0.217013889 MEGA

3) 일일 마이닝 수량: 18,750 MEGA

4) 반감기: 4년

5) 토큰 컨트랙트: EQB-cCOQDwerEnUD4–6xoYD0eL6_yC1zogAvA5GuXTF0iDIf


TON Explorer — The Open Network



A. MEGA 초기 발행량

메가톤 파이낸스의 초기 생태계를 구축하기 위해 1,000,000 MEGA(전체 발행량의 1%)를 마케팅, MEGA LP 인센티브 및 Tonstarter에 활용합니다. 메가톤 파이낸스는 초기 공급량을 활용한 이벤트로 사용자와 유동성을 확보해 톤 네트워크상에서 안정적인 거래 환경을 조성할 것입니다.


B. MEGA 최종 토큰 분배량

MEGA의 최종 분배량은 100,000,000 MEGA이며 위의 표와 같이 분배됩니다.


메가톤 파이낸스에 많은 참여 부탁드립니다.


메가톤 파이낸스의 개발사 오지스는 클레이스왑, 메시스왑 등 디파이 프로토콜을 개발하고 운영하면서 세계적인 수준의 TVL과 MAU를 달성한 바 있습니다. 이러한 경험을 바탕으로 톤 생태계 위에 사용자 친화적인 DEX를 출시했습니다.


현재 메가톤 파이낸스는 소개 부분에서 언급했듯이 라우팅 기능이 없습니다. 유니스왑 V1처럼 WTON을 기반으로 생성된 각 페어를 2번 스왑해야 원하는 토큰을 획득할 수 있습니다. 오지스는 이로 인해 발생할 사용자들의 불편을 잘 인지하고 있습니다. 톤 블록체인이 업그레이드되면 유니스왑 V2와 같이 즉각적으로 스왑이 가능한 기능을 신숙하게 구현하도록 하겠습니다.


추후 메가톤 파이낸스에 레버리지 파밍, 거버넌스, 롱/숏 포지션 예치 등 다양한 금융 서비스가 추가되면 일반적인 거래소 이상의 금융 경험을 제공할 것입니다. 따라서 메가톤 파이낸스 생태계에는 MEGA 장기 투자자, MEGA 스테이킹을 통해 거버넌스에 참여하려는 사용자, 다양한 디파이 서비스를 단기적으로 이용하는 사용자 등 다양한 유형의 사용자가 참여할 수 있습니다. 더 나아가, 메가톤 파이낸스와 텔레그램 간 완벽한 결합으로 톤 생태계 참여자뿐만 아니라, 텔레그램 사용자들도 쉽게 사용할 수 있는 프로토콜로 자리매김하겠습니다.


그동안 톤 블록체인 기반의 디파이를 경험하고 싶었지만 생소한 UI/UX와 메이저 자산의 부재 등으로 어려움을 겪었던 모든 분에게 메가톤 파이낸스는 새로운 기회가 될 것으로 기대합니다. 톤 생태계에 활력을 불어넣을 메가톤 파이낸스에 많은 참여 부탁드립니다!



메가톤 파이낸스

공식 홈페이지:



텔레그램 (공지):

텔레그램 (글로벌):

텔레그램 (국내):



팀 & 제품


오르빗 체인:

오르빗 브릿지:

벨트 파이낸스:




WTON 게이트웨이:


메가톤 파이낸스 정식 출시

안녕하세요 메가톤 파이낸스 커뮤니티 여러분 !




오지스 메가톤(JETTONS) 관련 링크


Orbit Bridge Ton Meshswap Protocol

Orbit Bridge Ton Ethereum

Orbit Bridge Ton USD Tether

Orbit Bridge Ton USD Coin

Orbit Bridge Ton Matic Token

D-3! 론칭 기대하고 계시나요?

드디어 2023년 1월 30일 메가톤 파이낸스가 론칭 될 예정입니다.


메가톤 파이낸스 커뮤니티 여러분 안녕하세요.

톤(Toncoin)의 상호운용성 문제에 대한 솔루션인 WTON 게이트웨이 출시 소식을 안내해드립니다.

자세한 사항은 아래 내용을 확인해주시기 바랍니다.

1. WTON 게이트웨이 소개

TON ↔ WTON 게이트웨이는 톤(Toncoin)을 젯톤(Jetton) 표준인 랩트톤(WTON)으로 변환해주는 서비스를 제공합니다. 랩트톤은 톤(TON: The Open Network) 블록체인 출시 이후 개발된 젯톤 토큰 표준으로, 톤 블록체인에서 토큰이 전송되는 방식 및 토큰 간의 일관된 전송 기록을 유지하는 방법을 정의합니다. 랩트톤은 톤 네트워크 내의 톤과 1:1로 지원되는 최초의 젯톤 표준 토큰입니다.

기존 톤 보유자는 가상자산 거래소에서만 활용 및 거래가 가능했습니다. WTON 게이트웨이에서 톤을 랩트톤으로 변환함으로써 메가톤 파이낸스를 비롯한 톤 생태계의 디파이 프로토콜에서도 톤을 사용할 수 있습니다. 또한, 언랩(unwrap) 기능을 사용하여 랩트톤에서 다시 톤으로 변환할 수 있습니다.

2. WTON 게이트웨이 출시 배경

톤은 글로벌 메신저 플랫폼인 텔레그램이 설계한 레이어 1 블록체인인 톤의 네이티브 토큰입니다. 하지만 톤 블록체인의 기축통화인 톤은 다른 EVM 기반 코인 및 알트코인과 호환하지 않습니다. 각각의 블록체인은 별개의 시스템이므로, 기본적으로 특정 블록체인에 존재하는 코인은 다른 블록체인에서 활용할 수 없습니다. 하지만, 우리 팀은 고립된 톤 블록체인을 활성화하고, 톤 블록체인의 기술력과 문화적 다양성을 기반으로 하는 톤 생태계를 구축하기 위해서는 가장 먼저 톤의 활용성을 제고하는 것이 필요하다고 판단했습니다. 이에 끊임없이 고민한 결과, 톤의 상호운용성 문제를 래핑(wrapping)이라는 방법으로 해결할 수 있다는 결론을 도출했습니다.

래핑은 ‘랩트톤’이라는 톤과 동등한 토큰을 패키징이 아닌, 스마트 컨트랙트를 통해 거래하는 것을 의미합니다. 쉽게 말해, 래핑이란 블록체인 간 비(非)상호운용성이라는 제한을 우회하여 다른 블록체인에서 토큰을 사용하는 방법입니다. 앞서 언급한 대로, 톤 블록체인에 존재하는 톤은 다른 블록체인에서 활용할 수 없습니다. 하지만 WTON 게이트웨이에서 톤을 래핑함으로써 메가톤 파이낸스를 비롯한 톤 메인넷의 디앱에서 톤을 활용하고, 다른 EVM 기반 토큰과 교환 및 거래할 수 있습니다.

3. WTON 게이트웨이 기대 효과

톤을 스마트 컨트랙트를 기반으로 한 다양한 기능에서 활용하려면 젯톤 표준 토큰인 랩트톤으로 변환해야 합니다. WTON 게이트웨이에서 랩트톤으로 변환함으로써 톤 블록체인에 구축된 기본 통화인 톤의 사용 범위를 확장할 수 있습니다.

즉, 랩트톤은 블록체인의 상호운용성 문제에 대한 솔루션입니다. 랩트톤은 젯톤 표준의 유연성을 갖춘 토큰으로, 탈중앙화된 플랫폼들에서 ETH를 자유롭게 다른 토큰들과 호환할 수 있도록 ERC-20 토큰화한 랩트이더(wETH)와 같은 역할을 할 것입니다. 톤과 랩트톤은 언제든지 1:1로 교환이 가능하고, 랩트톤은 다양한 디앱에서 ETH, USDT, USDC, MATIC 등 다양한 ERC-20 토큰으로 교환 및 스왑이 가능합니다.

사용자는 랩트톤을 톤 블록체인 기반의 DEX인 메가톤 파이낸스를 비롯한 여타 톤 생태계 내의 디파이 프로토콜에서 활용할 수 있습니다. 또한, 이더리움, 폴리곤, 클레이튼 등 다른 블록체인 내의 다양한 디파이 프로토콜에서 주요 암호화 자산으로 발돋움할 뿐만 아니라, 멀티체인 유니버스를 오가는 사용자를 연결하는 매개가 될 것으로 기대합니다.


[WTON 게이트웨이 사용자 가이드 및 참고사항]

  • WTON 게이트웨이 사용자 가이드
  • WTON 게이트웨이를 통해 톤 래핑(wrapping) 시 랩트톤으로 전환되고, 언랩(unwrap) 기능 활용 시, 다시 TON으로 변환 가능
  • TON 블록체인 지원 지갑: TON Wallet, Tonhub (추후 Tonkeeper, Tonic, OpenMask, Coin98 Wallet 지원 예정)

오지스는 수년간 다양한 블록체인 프로젝트와 긴밀히 협력해 유기적 블록체인 기술을 축적했고, 인프라도 구축했습니다. 지금까지 쌓은 경험과 노하우를 바탕으로 메가톤 파이낸스와 WTON 게이트웨이를 출시했습니다. WTON 게이트웨이는 기존 톤 블록체인에서 활용성이 부족했던 톤을 사용할 수 있게 함으로써 사용자, 재단, 다양한 디파이 프로토콜과 메가톤 파이낸스 간 연결고리 역할을 수행할 것입니다. 톤 블록체인 연결로 7억명의 텔레그램 유저를 품고, 나아가 국경의 경계 없이(Borderless) 전 세계 사용자를 포용하는 디파이 프로토콜로 성장할 메가톤 파이낸스의 미래를 기대 바랍니다. 여러분의 변함없는 관심과 지속적인 성원을 부탁드립니다.


메가톤 파이낸스


팀 & 제품


WTON 게이트웨이 출시

메가톤 파이낸스 커뮤니티 여러분 안녕하세요.


텔레그램 톤 네트워크 검증자, 온체인 거래 없는 비활성 주소 동결 투표 - 토큰포스트

사진 = shutterstock

텔레그램의 톤(TON, 디오픈네트워크) 네트워크 검증자들이 거버넌스 투표를 진행할 것으로 전망된다.

24일(현지시간) 텔레그램의 톤 네트워크 검증자들이 초기 유통 기여자들 중 온체인 거래를 한 적이 없는 195개 장기 비활성 주소를 향후 4년간 동결하는 방안에 대한 거버넌스 투표를 진행한다.

해당 주소들은 현재 약 25억 달러(한화 약 3조875억원) 상당의 10억8000만개 TON을 보유하고 있다. 이는 TON 유통량의 21.3% 규모다.

해당 제안이 통과되려면 검증자 중 최소 75%가 여러 차례로 나눠 진행되는 투표에 참여해야 한다. 또 제안 통과 시 동결 대상 주소들은 4년간 아무런 거래도 할 수 없으며, 퍼블릭 체인 상에서 동결 주소 목록을 상시 확인 가능하다.

이와 관련 톤코인 재단은 "해당 제안은 TON 커뮤니티의 투명성을 증명하기 위함"이라며 "해당 지갑들의 동결을 통해 TON 유통량을 보다 투명하게 공개할 수 있다"고 설명했다.

한편, 지난 5일 톤 재단이 데이터 스토리지 시장에 진출한 것으로 나타났다.

톤 재단은 자체 개발 데이터 스토리지 솔루션 '톤 스토리지'(TON Storage)을 출시해 TON 코인을 인센티브로 제공하는 데이터 스토리지 프로젝트를 추진한다.

사용자의 데이터를 분산해 보관하는 노드 운영자들은 스마트 컨트랙트를 통해 TON 코인을 보상으로 지급받을 수 있으며, 이를 통해 사용자는 사실상 영구적으로 데이터를 저장할 수 있다는 게 톤 재단 측의 설명이다.


텔레그램 톤 네트워크 검증자, 온체인 거래 없는 비활성 주소 동결 투표 - 토큰포스트

텔레그램의 톤(TON, 디오픈네트워크) 네트워크 검증자들이 거버넌스 투표를 진행할 것으로 전망된다.24일(현지시간) 텔레그램의 톤 네트워크 검증자들이 초기 유통 기여자들 중 온체인 거래를 한


The Open NetworkJanuary 27, 2022

다음은 Exchange가 2022년 1월 23일 앤드류 로고조프와 나눈 텔레그램 대화와 AMA에서 가졌던 질의응답을 정리한 내용입니다. 모든 질문과 답변은 그룹의 원본 메시지에 연결되었습니다.


Q: x 톤코인AMA가 5분 후에 시작됩니다

여러분, 안녕하세요. 오늘 톤코인과 함께하는 AMA 이벤트에 참여해 주셔서 감사합니다.

TON 재단의 창립 멤버이자 VK.com의 전 CEO인 앤드류 로고조프가 여러분의 질문에 답변해 드릴 것입니다. 앤드류 씨를 따뜻하게 맞아 주시기 바랍니다!


안녕하세요 여러분! 오늘 이 자리에 함께 하게 되어 기쁩니다.


저는 오늘 이 시간 사회를 맡게 될 Bit.com의 제프리입니다. 이제 AMA를 시작하겠습니다.

바쁘신 가운데 함께 해주셔서 감사합니다. The Open Network가 무엇인지 설명해 주실 수 있을까요?


물론이죠. The Open Network를 의미하는 TON은 완전히 작동하는 레이어 1 지분증명 블록체인으로, 무한한 수평적 확장성을 통해 초당 수백만 건의 트랜잭션을 처리하고 수십억 명의 사용자들과 스마트 컨트랙트 그리고 탈중앙화 애플리케이션을 수용하고자 자연스럽게 성장하도록 설계되었습니다.

이것은 니콜라이 두로프 박사(텔레그램의 CTO)가 만든 설계를 바탕으로 텔레그램 팀이 구축했고 2020년 후반에 커뮤니티에 인계되었습니다. 전 세계의 헌신적인 개발자들로 구성된 그룹이 비영리단체인 TON 재단을 세워 지금은 텔레그램의 개입 없이 네트워크 인프라의 발전을 위해 노력하고 있습니다.


대단하군요! 그래서 지금 얼마나 많은 이들이 TON을 사용하고 있는지 대략적인 수치를 알려주실 수 있나요?


오늘날 블록체인에는 160,000개 이상의 활성 계정이 있습니다. 소셜 미디어의 활성 커뮤니티에는 총 1백만 명이 넘는 회원들이 활동하고 있습니다.

미리 수집된 질문

160,000이라는 숫자는 결코 적은 수가 아닙니다. 그리고 우리 모두 파벨이 몇 주 전에 TON을 지지한다는 소식을 접해 알고 있습니다. 우리는 TON의 밝은 미래를 볼 수 있습니다.

TON에 대해 소개해 주셔서 감사합니다. 사용자에게 받은 미리 수집된 질문부터 여쭤보겠습니다.


투자자의 약 3/4가 프로젝트의 진정한 가치와 건전성을 이해하지 않고 단기적 관점을 내세워 토큰의 가격에만 집중하고 있습니다. 투자자들이 귀하의 토큰을 장기적으로 보유하게 된 동기와 이점에 대해 말씀해 주시겠습니까?


우리는 톤코인이 대규모 사용자 기반을 갖춘 텔레그램과 같은 사용자에게 익숙한 인터페이스를 통해 대중 시장 서비스에 접근하는 최초의 암호화폐가 될 것이라고 믿습니다.

TON 네트워크는 TON 저장소, TON 사이트, TON DNS 등의 모듈을 포함해 최상의 Web 3.0 개발을 지향하고 있습니다. 올해 2022년 이 기간 동안 TON 네트워크는 톤코인이 주요 결제 수단 및 가치 저장 수단으로 기본 통합되는 다양한 제품 및 서비스를 특징으로 한 글로벌 Web 3.0 네트워크의 형태를 취할 것입니다.

텔레그램 메신저와 같이 대중을 대상으로 하는 제품을 만들고 이러한 제품으로 통합하려는 계획을 비롯해 톤코인의 뛰어난 사용 사례로 구성된 세트를 마련할 것입니다.

따라서, 톤코인은 토큰 보유자들이 이러한 탈중앙화 서비스와 유망한 Web 3.0 개념의 진화에 참여할 수 있게 할 것입니다.


톤코인의 가장 고유한 기능은 무엇이고, 토큰 보유자는 장기적으로 어떤 이득을 얻을 수 있을까요?


TON 네트워크의 네이티브 코인인 톤코인은 TON 커뮤니티에서 출시했거나 개발 중인 대중 고객 지향 제품의 필수 부분입니다. TON 네트워크의 Web 3.0 서비스에 대한 결제 수단으로서의 효용 가치는 시장의 다른 코인과 비교했을 때 고유한 포지셔닝을 만듭니다.


강력한 커뮤니티는 프로젝트에 흥미로운 아이디어를 가져올 뿐만 아니라 더 큰 파트너를 끌어들입니다. 그렇다면 TON은 커뮤니티를 어떻게 구축하려고 하는 걸까요? 그리고 블록체인 경력이 있는 전문가들을 팀에 영입할 계획이 있나요?


TON 커뮤니티는 매우 빠르게 성장하고 있습니다. 다른 많은 프로젝트들과 달리 TON은 사람들을 모집하거나 고용하지 않고 TON의 비전에 대한 열정과 믿음을 통해 자발적으로 참여하도록 동기를 부여하는 진정한 탈중앙화 커뮤니티를 가지고 있습니다. 이는 주변에 활발한 개발자 커뮤니티가 있는 텔레그램의 특성 때문이기도 합니다.

50명 이상의 재능 넘치는 개발자들이 현재 클래식 백엔드 및 프론트엔드 개발자, 암호화폐 개발자, 고부하 솔루션 개발자 및 암호화폐 자문을 포함한 다양한 팀 내에서 TON 작업을 진행하고 있습니다. 그 밖에도, 커뮤니티에는 마케팅 전문가, PR 팀 및 비즈니스 개발 전문가도 포함됩니다. 그리고, 커뮤니티는 다양한 역할을 채워줄 TON 가족에 합류할 수 있는 새로운 프로젝트, 기업가 및 블록체인 전문가들의 합류를 환영하고 이런 분들을 지속적으로 찾고 있습니다.

우리는 기업가와 개발자들이 TON을 기반으로 최고 품질의 블록체인 프로젝트를 만들 수 있는 여러 대규모 커뮤니티 인큐베이터를 런칭하는 과정에 있습니다. 인큐베이터는 생태계가 번성할 수 있도록 기술적 조언, 재정 및 사회적 자본을 제공할 것입니다.


많은 신생 기업들이 멋진 첫 인상을 가지고 탄생했지만 한 순간에 쇠퇴의 길을 걸었습니다. 시장에서 발판을 마련하고 블록체인 세계에서 가장 위대한 토큰으로 자리매김하기 위해 The Open Network를 어떻게 이끌어 가실 것인지 설명해 주실 수 있을까요?


TON 커뮤니티와 개발 핵심 팀은 지난 몇 년간 극심한 불확실성 속에서도 지속 가능한 존재로 입증되었습니다. 텔레그램의 TON 프로젝트 참여가 중단된 날부터 지금까지 개발 커뮤니티는 TON(의 원래 아이디어에서 구상했던 글로벌 Web 3.0 네트워크를 실행하겠다는 약속을 이행하겠다는 약속을 입증했습니다. 이 커뮤니티는 상당히 분산되었고, 더 이상 어느 한 그룹이나 특정 개인이 네트워크의 중요한 병목이 되거나 또는 실패 지점이 아닙니다. 이 모든 것이 제게 장기적으로 TON 프로젝트의 지속 가능한 개발에 대한 확신을 줍니다.

우리는 장기적인 비전을 가지고 있으며 이것은 ton.org에서도 찾을 수 있는 최신 로드맵입니다.



TON은 더 큰 암호화폐 시장에 어떻게 진출할 계획인가요?


TON 커뮤니티는 사용하기 쉬운 제품 형태로 대중 시장 솔루션을 제공하는 데 중점을 두고 있습니다. 우리는 블록체인을 사람들의 기본적인 요구를 충족시키는 데 사용되는 기술로 봅니다. 우리의 목표를 달성함에 따라 우리는 암호화폐 시장에서 시장 점유율을 확보할 수 있을 뿐 아니라, 가치 송금, 데이터 저장, 데이터 액세스, 지적 권리 보존 및 블록체인 기술과 Web 3.0이 가져온 혁신도 이룰 수 있게 될 것입니다.

추가 질문 5개

감사합니다! 사용자들이 TON에 대해 더 많은 질문이 있을 것 같아서 이제 질문을 5개만 더 드리겠습니다.


사용자들은 어떻게 이 프로젝트에 대한 최신 정보를 받을 수 있나요? 사용자들이 최신 업데이트를 받을 수 있는 로컬 커뮤니티를 포함한 채널이 있나요?


TON 관련 업데이트를 확인하는 가장 좋은 방법은 다양한 언어로 제공되는 공식 텔레그램 채널을 구독하는 것입니다.

• 영어:

• 러시아어:

• 우즈베키스탄어:

• 스페인어

• 인도네시아어:

• 아랍어:

• 한국어:

• 터키어:

• 중국어(간체):

• 중국어(번체):

• 이탈리아어:


스마트 컨트랙트가 되려면 즉각적이고 수수료 없는 비공개 트랜잭션이 되어야 합니다. 톤코인이 이 3가지 문제를 해결할 수 있을까요?


예, 그렇습니다.

1. 즉각성을 말하자면, TON은 대기시간이 짧은 트랜잭션용으로 설계되었습니다. 이 블록체인은 초당 수백만 건의 트랜잭션을 수용할 수 있고 평균 블록 처리 시간은 3~7초에 불과합니다.

2. 네트워크 지속 가능성을 위해 수수료가 부과되지는 않지만 TON의 수수료는 트랜잭션당 미화달러 센트의 극히 일부로 상당히 낮아 세계에서 가장 비용 효율적인 블록체인 중 하나가 됩니다.

3. 비공개 트랜잭션은 핵심 기술의 장점 중 하나인 특정 TON 워크체인에 의해 지원될 수 있습니다.


파트너십은 채택에 필수인데, 현재와 미래에 어떤 파트너와 제휴할지 알려주실 수 있을까요?

관리자 추가 내용:

이 질문에 대해 조금 정정하겠습니다. 우리는 TON이 텔레그램과 긴밀한 관계를 맺고 있는지, 텔레그램과의 통합이 있는지, 톤코인을 필요로 하는 프리미엄 기능이 추가될지 여부를 알고 있습니다. 이 코인(결제에 사용됨)은 향후에 소각될 예정인가요?


지금까지 텔레그램과 두 가지 통합이 이루어졌습니다. 첫째는 u/wallet 봇으로, 사용자가 TON 지갑을 텔레그램 계정과 연결할 수 있게 해줍니다. 암호화폐의 구매 및 교환을 지원할 뿐 아니라 다른 텔레그램 사용자와 주고 받을 수도 있습니다. 이 봇은 텔레그램 내부에 존재하기 때문에 사용자가 월렛을 사용하기 위해 메신저 앱을 나가지 않아도 됩니다.

또 다른 통합을 통해 콘텐츠 제작자는 텔레그램에서 톤코인으로 결제액을 받을 수 있습니다. 이것은 사용자가 구독 기반으로 개인 채널에 접근할 수 있는 페이월 기능입니다. 패트리온(Patreon)과 거의 같거나 최근 인스타그램에서 유료 구독을 런칭했습니다. 이 서비스는 TON, 톤키퍼 월렛 그리고 @donate 봇 팀 간의 협력으로 만들어졌습니다. 현재 비공개 베타 버전이지만 스크린샷에서 작동 방식을 확인할 수 있습니다. 가까운 장래에 이 서비스는 비공개 채널뿐 아니라 비공개 그룹 채팅용으로 텔레그램의 모든 사용자에게 공개될 예정입니다.

1분기에 런칭할 더 많은 통합들이 있지만 아직 구체적으로 공개하지는 않을 것입니다. 제가 밝힐 수 있는 것은 가능한 한 많은 사용 사례를 6억 이상의 텔레그램 대중 전체에 전달하는 것이 목표라는 것입니다.

텔레그램에 통합된 제품에서 발생할 수 있는 모든 지불은 제작자 또는 서비스 제공자에 대한 지불입니다. 따라서 이들에게 지불되고 불태워지지 않을 것입니다. 이러한 제품 내에서 텔레그램은 텔레그램의 개입 없이 이루어지기 때문에 지불 수수료를 징수하지 않습니다.

텔레그램은 블록체인이 가질 수 있는 가장 전략적인 파트너 중 하나이지만 TON은 텔레그램을 넘어서는 것을 목표로 합니다. TON은 이미 OKEx, FTX, 톤키퍼, @wallet, @donate, Mercuryo 및 NeoCrypto를 포함한 최상위 거래소, 월렛, 페이먼트 게이트웨이들과 파트너십을 맺고 있습니다.


귀사 웹사이트에서 스마트 컨트랙트에 대한 내부 또는 외부 감사를 실시했던 적이 있다고 언급하지 않으셨는데, 이전에 감사를 하셨던 적이 있다면 상세히 알려 주실 수 있을까요? 감사를 하셨던 적이 없다면, 가까운 장래에 스마트 컨트랙트를 어느 하나라도 검토할 계획이 있으신지요?


TON은 견고함을 염두에 두고 설계되었습니다. TON의 보안 모델은 보수적 가정과 동료들이 검토한 프로토콜을 기반으로 합니다. 그리고 우리는 Trail of Bits를 포함한 핵심 블록체인 구성요소 및 스마트 컨트랙트에 대한 감사를 통과하기 위해 여러 최고 보안 기관과 협력합니다. 시간 관계로, 해당 결과가 나오는 대로 커뮤니티 최신 소식을에 계속 게시하도록 하겠습니다.


톤코인은 채택을 현실, 사회적 및 실제 사용 사례로 만들기 위해 무엇을 했나요?,


현재 작업 중인 모든 사용 사례를 대중화하기 위해 다양한 인센티브와 함께 전통적인 접근법을 활용해 서비스를 시도해 볼 것입니다. Telegram Ads 플랫폼의 폭 넓은 지지와 함께, 우리는 아직 암호화폐에 익숙하지 않은 분들을 포함해 더 폭 넓은 대중에게 다가가고 있습니다. 앞서 설명한 사용 사례도 채택률을 높이는 데 도움이 됩니다. 임계치에 오면 이 역학(송금, 기부, 구독 등)에 대한 바이럴 효과가 자체적으로 확산되어 최초의 대중시장 암호화폐 서비스로 자리매김할 것입니다.


현재 NFT는 화두이지만 기술만을 위한 NFT는 아닙니다. 귀사 프로젝트는 시간이 지남에 따라 더 많은 실제 사용 사례가 NFT에 대해 나타날 것이라고 생각하시나요? NFT를 왜 진지하게 받아들여야 할까요?

관리자 추가 내용:

NFT는 암호화폐 공간에서 화두 중 하나로 손꼽히니, 앤드류에게 물어볼 질문을 하나 더 선택하겠습니다. 앤드류가 기꺼이 대답해 줄 것 같은데요. 그렇죠?


이 질문을 해주셔서 감사드립니다. 제가 가장 좋아하는 질문이거든요 

우선 NFT는 게임에서 두드러집니다. 유용한 아티팩트를 NFT로 발행하고 게임 내 경제성을 향상시킬 수 있습니다. 그리고 TON은 고성능 탈중앙화 경제 레일을 사용해 게임이 마침내 상호운용될 수 있기 때문에 게임 업계에서 정말 멋진 플랫폼입니다.

원래 NFT는 도메인 이름이지만, DNS는 항상 중앙집중식이고, 보안 문제로 가득 차 있었고, 블록체인 대안은 확장할 수 없었습니다. TON은 고유한 이름의 소유권이 잘 맞는 저장소 및 분배 시설도 제공하기 때문에 이런 부분에서 상황을 바꿀 수 있습니다. TON NFT는 차세대 SocialFi의 기반이 될 것입니다.

오늘날 TON 생태계에는 여러 NFT 프로젝트와 계약 표준이 존재합니다. 강력한 TON NFT와 대체 가능한 토큰은 핵심 요소를 기반으로 하는 다양한 제품과 서비스의 문을 여는 2022년 1분기 말 이전에 런칭될 예정입니다. 이들 중 일부는 관련 대중에게 서비스를 제공하기 위해 소셜 네트워크에 통합될 것입니다.

TON의 첫 번째 NFT는 TON 다이아몬드(가 될 것입니다. 이 이면의 아이디어는 멋진 사진을 가질 뿐만 아니라 소유자가 돋보이게 하고 예정된 기능 및 이벤트에 대한 조기 독점 이용 자격을 얻을 수 있도록 TON 월렛, 익스플로러, NFT 마켓플레이스 및 TON 생태계의 다른 부분에도 사진을 통합하는 것입니다. TON 다이아몬드는 커뮤니티가 스스로를 표현할 수 있게 합니다.


좋습니다. 우리 모두 다 더 많은 NFT 프로젝트들이 TON에 모이기를 기대하고 있습니다.

오늘 시간 내주신 앤드류와 함께 해주신 모든 분들께 다시 한 번 감사드립니다.


질문해 주셔서 감사드립니다. 즐거운 시간 되시기 바랍니다!

결론 및 TON도 팔로우해주시기 바랍니다.

질문에 채택 되신 분들께는 근무일 기준 7일 이내에 보상을 지급해 드립니다. 앞으로 더 많은 톤코인 에어드랍 이벤트가 있을 예정입니다.

다음 주에 또 다른 인기 토큰과 함께 진행되는 AMA의 다음 라운드를 기대해 주십시오!


출처 : AMA에서 만난 앤드류 로고조프와의 질의응답 정리

다음은 Exchange가 2022년 1월 23일 앤드류 로고조프와 나눈 텔레그램 대화와 AMA에서 가졌던 질의응답을 정리한 내용입니다. 모든 질문과 답변은 그룹의 원본 메시지에 연결되었습니다. 소개




The Open Network(TON)은 매우 높은 확장성을 목표로하는 Layer1 프로토콜로, 지분 증명 방식과 무제한 샤딩(Infinite Sharding Paradigm)을 통하여 현존 최고 수준의 TPS를 구현했다. 최근 페이스북 개발자 출신이 만든 Aptos와 SUI가 차세대 이더륨 킬러로서 큰 관심을 받고 있는 가운데, TON은 기술력 뿐만 아니라 Telegram 메신저와의 연계로 블록체인의 mass adoption을 이끌어 낼 유력 주자로 부상하고 있다.

TON은 열악한 시장 여건에도 불구하고 Telegram 내 wallet 기능 등을 추가하면서 저변을 꾸준히 확대했고, 이를 기반한 가격 상승으로 최근 Coinmarketcap 기준 30위권에 진입했다. 특히, DEX 및 NFT marketplace와 같은dApp을 메타마스크가 아닌 Telegram 메신저 브라우저를 통해 이용할 수 있는 WebApp 방식을 활용함으로써 일반 이용자들의 접근성을 크게 높였다.



TON은 현재 FTX, Huobi, OKX 등에서 거래할 수 있고, 거래소에 따라 $TON 또는 $Toncoin이라는 티커를 사용하고 있다. 현재 업비트에 상장되어 있는 TON은 토카막(Tokamak Network)으로 The Open Network와는 무관한 프로젝트이기에 유의할 필요가 있다.

참고로, TON은 Telegram이 만든 Gram의 레거시를 잇는 프로젝트로 오픈소스로 공개된 코드를 활용, 기존 대비 보다 개선된 기술력으로 크립토 시장에 도전장을 내밀었다. Telegram과의 히스토리는 다음 포스팅에서 자세히 다루도록 하고, 이번엔 TON의 압도적 확장성을 가능케한 동작 메커니즘에 대해서 살펴보려고 한다.

|TON 블록체인 기술력 심층 분석

TON은 결제 시스템뿐만 아니라 다양한 탈중앙 서비스를 제공하기 위한 완전한 인프라를 구축하는 것을 목표로 한다. 이를 가능케할 높은 확장성을 담보하기 위해 TON은 다음과 같은 기술을 활용하고 있다.


|높은 확장성을 위한 지분증명(PoS) 및 샤딩(sharding)

TON은 세가지 계층 네트워크로 구성되어 있다. 첫 번째 계층에는 빠른 속도와 보안을 제공하는 지분 증명(PoS) 알고리즘을 기반으로 하는 마스터체인(masterchain)이 있다. 이 마스터 체인은 현재 운영 중인 TON 네트워크의 메인 체인이며 TON에서 수행되는 모든 연산이 마스터체인에서 이뤄진다.

두 번째 계층에서는 작업체인(workchain)이 존재하는데, 일종의 보조체인으로 마스터체인 뿐만 아니라 동시에 다른 작업체인 모두와 연결되어 데이터를 공유한다. 즉, N개의 작업체인 있다면 N^N개의 상호 연결이 존재하여 작업을 공유하는 것이다. 이러한 2차 체인 각각은 서로 다른 형식의 계정 주소, 스마트 계약 및 가상머신을 통해 고유한 합의 규칙(consensus rules) 세트를 갖출 수 있다. 이 모든 과정에서 마스터체인과의 호환성을 유지하는 동시에 각 작업체인 간의 원활한 상호 작용이 가능하다.

마지막으로 세 번째 계층에는 샤드체인(shardchain)이 있는데, 샤드체인은 작업 체인의 일부이며 그 역할은 작업을 분할하고 병렬화하여 확장성을 개선시키는 것이다. 이러한 방식으로 TON의 확장성은 현재 Polkadot(~1500 tps) 또는 Solana(~65,000 tps)보다 훨씬 높은 초당 수백만 건의 거래를 처리할 수 있는 수준으로 개선된다. 이는 샤드체인을 활용한 bottom-up 접근법 덕분에 가능한 것으로 TON에서는 이 방식을 무한 샤딩 패러다임(Infinite Sharding Paradigm)이라고 부른다.



이러한 기술을 바탕으로 TON이 Ethereum, Polkadot 또는 Cosmos와 같은 메인넷과 직접적으로 경쟁할 수 있는 기반을 마련했다고 할 수 있다. TON의 전체 메커니즘은 P2P 프로토콜을 통해 완전히 탈중앙화된 방식으로 작동하기 때문에 검열저항성 뿐만 아니라 네트워크가 겪을 수 있는 다양한 공격에 견딜 수 있도록 설계됐다.




|자가 치유, 하드 포크 없는 네트워크

TON 블록체인의 또 다른 주요 혁신에는 자가 치유(self-healing) 또는 자가 복구 메커니즘(self-recovery mechanism)이 있다. 작업을 병렬 처리하는 샤딩으로 인해, 마스터체인의 업데이트가 하위 계층(워크체인 또는 샤드체인)와 충돌할 가능성이 있다. 자가 치유 메커니즘은 이러한 충돌이 발생했을 때 TON 네트워크가 적절한 기능을 유지하도록 하는 역할을 하고, 경우에 따라 문제 해결을 위해 블록을 다시 쓸 수(rewriting the blocks) 있도록 해준다.

물론, 어떤 경우에도 block rewriting이 이전에 생성된 블록을 버린다는 것을 의미하지 않는다. 해당 블록의 기존 데이터는 온전히 새 블록에 연결되어 언제든 지속적으로 관련 정보를 리뷰할 수 있기 때문이다. 이를 통해 TON은 블록체인을 위협하는 이벤트로부터 스스로를 보호하는 동시에, 구조적으로 발생할 수 있는 원치 않는 하드 포크를 방지할 수 있다.


|Instant Hypercube Routing을 통한 네트워크 이슈 해결

아이러니하게도 블록체인 네트워크가 직면해야 하는 가장 큰 문제 중 하나는 네트워크의 성장 그 자체다. 이용자 증가에 따라 기하급수적으로 상승하는 P2P구조의 네트워크 복잡성은, 블록체인 운영주체가 기존 합의된 규칙에 따라 모든 부분에 정보를 송수신하는데 갖가지 어려움을 발생시킨다.

우편 또는 택배회사의 예를 들어 쉽게 설명하자면, 이 회사가 100명의 고객을 커버하는 데에는 큰 어려움이 없다. 그런데, 수천개의 우편사가 전세계 수 억명을 대상으로 서비스하기 위해서는 그 난이도가 기하급수적으로 상승하고 효율성에 중대한 문제가 생겨버린다. Solana와 같은 기존 블록체인이 이용자가 급증하면서 흔히 겪는 문제이기도 하다.


사실 이 점이야 말로 TON이 직면하고 있는 어려움이다. 앞서 언급했듯이, TON 네트워크는 N개의 작업체인이 마스터체인과 서로 다른 체인과 N^N개의 상호작용을 원활히 수행할 수 있어야 한다. TON은 Instant Hypercube Routing(IHR) 기술을 접목하여 수 많은 노드와 체인들이 빠르고 효율적으로 구동될 수 있도록 설계했다. 이를 통해, 5초마다 새로운 블록이 형성되는 무한 샤딩 패러다임 프로토콜 전체가 언제든 동기화를 유지할 수 있도록 한 것이다.

Instant Hypercube Routing(IHR)에 대하여 최대한 간단히 설명해 보자면, 완전히 같진 않지만 행렬연산법의 예를 들어 볼 수 있다. 5명의 사람이 서로 모두에게 메세지를 보내기 위해서는 5!(5x4x3x2x1=120)번의 작업이 필요하다. 컴퓨터로 따지면 총 120번의 연산이 필요한 작업인데, Hypercube Routing 기술을 활용하면 120번이 아닌 1번의 연산으로 이를 해결할 수 있다.

(여기서 부터는 어려울 수 있다.)각 노드를 한개 숫자의 variable이 아닌 여러 숫자로 이뤄진 벡터 또는 매트릭스(matrix)로 지정하는 것인데, 이를 통해 한 개의 숫자와 다른 숫자간의 연산을 반복하는 것이 아닌 매트릭스 간의 복합연산을 통해 빠르게 결과를 도출해낼 수 있는 것이다. 통상 여기에 활용되는 매트릭스의 차원이 우리에게 익숙한 2~3차원이 아니라 수백 수천 차원의 개념이라 바로 머릿속에 떠올리기는 어렵지만 컴퓨터를 통해 구현할 수 있다.

이 방식은 방대한 데이터를 다뤄야하는 통계 시스템에서 필수적으로 사용되기도 하며, 프로그램의 속도를 획기적으로 증가 시키는데 아주 중요한 역할을 한다. 이 방식을 네트워크간의 커뮤니케이션에 적용했다고 생각하면 된다.

사실 이 문제는 이더리움 2.0의 샤드체인 개발 과정에서 겪고있는 어려움이며, 지금은 해결됐으나 폴카닷 역시 비슷한 문제를 겪은 적이 있다.


1,2,3 차원 하이퍼큐브 설명 도식



5차원 하이퍼큐브 설명 도식


|개인 정보 보안 및 익명성

TON이 달성한 또 다른 큰 발전은 사용자의 개인 정보와 익명성을 유지하고 보호하는데 진일보한 기술을 선보였다는 것이다. 예를 들어, 지분증명 네트워크의 일반적인 문제는 모든 staker가 자신이 보유하고 있는 코인의 총량을 공개적으로 볼 수 있는 주소를 공개해야 하고, 공개되어서는 안 되는 데이터를 노출해야 하기도 한다.

이러한 상황을 피하기 위해 TON은 사용자가 네트워크에서 익명으로 정보를 교환할 수 있도록 하는 TON 네트워크의 기능인 TON 프록시를 만들었다. 이를 위해 TON은 I2P(Tor,The Onion Router,와 경쟁하며 보다 우수한 기술 능력을 갖춘 프로토콜)에서 파생된 네트워크 프로토콜을 사용한다. 이는 시스템이 TON 네트워크에서 익명으로 데이터를 보내고 받을 수 있도록 하고 TON을 사용할 때 사람들의 프라이버시와 익명성을 용이하게 하는 zeroconf(without the need for configuration)를 허용한다는 것이다.

TON 블록체인은 위에 설명한 기술 뿐만 아니라, 이더리움의 ENS와 같은 DNS서비스인 TNS 서비스를 이미 상용화했고, Filecoin 또는 Sia와 같은 네트워크 분산 데이터 저장 시스템(TON storage)을 갖추고 있다.


물론, 앞으로 해결해야할 관문도 산재해있다. 현재 TON은 고급 스마트 계약 기능을 제공하지만, 예를 들어, NFT와 같은 특수 계약을 배포하기 위한 표준 사양이 아직 부족하여 이에 적합한 특정 토큰의 출시는 작업체인으로 제한되고 있다. 또한, 기존에 많이 알려진 이더리움의 Solidity나 Rust 등 과같은 언어가 아닌 C언어에서 파생한 FunC라는 생소한 언어쳬게를 사용하는 것이 풍부한 개발자 환경을 개척하는데 어려움을 주고 있다.

다만, 전세계 MAU 5억명 사용자를 보유한 Telegram 메신저의 적극적인 협력 및 integration에 힘입어 관련 표준의 확립 및 개발자 pool의 빠른 확장에 대한 기대가 크다고 생각한다.


차세대 Layer1 TON(The Open Network) 심층 분석 | 줌 투자

한눈에 보는 국내 해외 증시 지수 정보와 전문가의 투자 인사이트를 줌 투자에서 확인하세요


+ Recent posts