Paradigm:이더리움 역사적 성장 문제 및 해결책 상세 설명

포사이트 뉴스
2024-05-12 17:05:09
수집
EIP-4444는 이더리움의 역사적 성장 문제를 해결하고 Gas 한도 증가를 위한 공간을 마련할 수 있습니다.

원문 제목:How to Raise the Gas Limit, Part 2: History Growth

원문 저자:Storm Slivkoff、Georgios Konstantopoulos

원문 편집:Luffy,Foresight News

역사 성장(History growth)은 현재 이더리움 확장의 최대 병목 현상입니다. 의외로 역사 성장은 상태 성장보다 더 큰 문제로 부각되고 있습니다. 몇 년 내에 역사 데이터는 많은 이더리움 노드의 저장 용량을 초과할 것입니다.

좋은 소식은:

  • 역사 성장은 상태 성장보다 해결하기 쉬운 문제입니다.
  • 해결책이 활발히 개발되고 있습니다.
  • 역사 성장을 해결하면 상태 성장 문제를 완화할 수 있습니다.

이 글에서는 1부에서 다룬 이더리움 확장 문제를 계속 탐구하며, 이제 상태 성장에서 역사 성장으로 주의를 전환합니다. 정교한 데이터 세트를 사용하여 우리의 목표는 1) 기술적으로 이더리움의 확장 병목 현상을 이해하고, 2) 이더리움 Gas 제한에 대한 최적 해법에 대한 논의를 촉진하는 것입니다.

역사 성장이란 무엇인가?

역사는 이더리움이 전체 생애 동안 실행한 모든 블록과 거래의 집합으로, 제네시스 블록부터 현재 블록까지의 모든 데이터를 포함합니다. 역사 성장은 시간이 지남에 따라 새로운 블록과 거래가 축적되는 것입니다.

그림 1은 역사 성장과 다양한 프로토콜 지표 및 이더리움 노드 하드웨어 제약 간의 관계를 보여줍니다. 상태 성장과 비교할 때, 역사 성장은 다른 하드웨어 제약에 의해 제한됩니다. 역사 성장은 네트워크 IO에 압박을 가하며, 새로운 블록과 거래는 전체 네트워크에 전송되어야 합니다. 또한, 역사 성장은 각 이더리움 노드가 전체 역사 기록의 복사본을 저장하기 때문에 노드의 저장 공간에도 압박을 가합니다. 역사 성장 속도가 이러한 하드웨어 제약을 초과할 경우, 노드는 더 이상 피어 노드와 안정적인 합의에 도달할 수 없습니다. 상태 성장 및 기타 확장 병목 현상에 대한 개요는 이 시리즈의 1부를 참조하십시오.

그림 1: 이더리움 확장 병목 현상

최근까지 각 노드의 대부분의 네트워크 처리량은 역사 기록(예: 새로운 블록과 거래)을 전송하는 데 사용되었습니다. Dencun 하드 포크에서 blob이 도입되면서 이러한 상황이 변화했습니다. blob은 이제 노드 네트워크 활동의 상당 부분을 차지하고 있습니다. 그러나 blob은 1) 노드가 2주 동안만 저장한 후 폐기되기 때문에 역사 기록의 일부로 간주되지 않으며, 2) 이더리움 제네시스 이후의 데이터를 반복할 필요가 없습니다. (1) 때문에 blob은 각 이더리움 노드의 저장 부담을 크게 증가시키지 않습니다. 이 글의 후반부에서 blob에 대해 더 논의할 것입니다.

이 글에서는 역사 성장에 중점을 두고 역사와 상태 간의 관계를 논의할 것입니다. 상태 성장과 역사 성장에는 일부 중복된 하드웨어 제약이 있으므로, 이들은 관련된 문제이며 하나의 문제를 해결하면 다른 문제를 해결하는 데 도움이 될 수 있습니다.

역사 성장은 얼마나 빠른가?

그림 2는 이더리움 제네시스 이후의 역사 성장률을 보여줍니다. 각 수직선은 한 달의 성장을 나타냅니다. y축은 해당 월의 역사 성장의 기가바이트 수를 나타냅니다. 거래는 '목표 주소'에 따라 분류되며 RLP(https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/) 바이트로 크기를 나타냅니다. 쉽게 식별할 수 없는 계약은 '알 수 없음'으로 분류됩니다. '기타' 카테고리는 인프라 및 게임과 같은 여러 작은 카테고리를 포함합니다.

그림 2: 이더리움 역사 성장률의 시간에 따른 변화

위의 그래프에서 몇 가지 주요 요점은 다음과 같습니다:

  • 역사 성장 속도는 상태 성장보다 6배에서 8배 빠릅니다: 역사 성장 속도는 최근 36.0 GiB/월로 정점에 달했으며 현재는 19.3 GiB/월입니다. 상태 성장 속도는 약 6.0 GiB/월의 정점에 도달했으며 현재는 2.5 GiB/월입니다. 이 글의 후반부에서는 역사와 상태의 성장 및 누적 크기 비교를 다룰 것입니다.
  • Decun 이전에 역사 성장률은 계속 가속화되었습니다: 상태는 수년간 대략 선형적으로 성장해왔지만(1부 참조), 역사는 초선형적으로 성장했습니다. 선형 성장의 성장률이 전체 규모를 제곱으로 증가시키는 반면, 초선형 성장의 성장률은 전체 규모를 제곱을 초과하여 증가시킵니다. 이러한 가속화는 Dencun 이후 갑자기 멈췄습니다. 이는 이더리움이 역사 성장률의 급격한 감소를 처음으로 경험한 것입니다.
  • 최근 역사 성장의 대부분은 Rollup에서 발생했습니다: 각 L2는 거래 복사본을 메인넷에 게시합니다. 이는 대량의 역사 기록을 생성하며, Rollup은 지난 1년 동안 역사 성장의 가장 중요한 기여자가 되었습니다. 그러나 Dencun은 L2가 역사 기록 대신 blob을 사용하여 거래 데이터를 게시할 수 있도록 허용하였으므로 Rollup은 더 이상 대부분의 이더리움 역사 기록을 생성하지 않습니다. 이 글의 후반부에서 Rollup에 대해 더 자세히 설명할 것입니다.

이더리움 역사 성장의 가장 큰 기여자는 누구인가?

다양한 계약 카테고리에서 생성된 역사 양은 이더리움의 사용 패턴이 시간이 지남에 따라 어떻게 진화했는지를 드러냅니다. 그림 3은 다양한 계약 카테고리의 상대적 기여도를 보여줍니다. 이는 그림 2와 동일한 데이터를 표준화한 것입니다.

그림 3: 다양한 계약 카테고리가 역사 성장에 기여한 정도

이 데이터는 이더리움 사용 패턴의 네 가지 다른 시기를 드러냅니다:

  • 초기(보라색): 이더리움의 초기 몇 년 동안 거의 체인 상의 활동이 없었습니다. 이러한 초기 계약 중 대부분은 현재 식별하기 어려우며, 그래프에서 '알 수 없음'으로 표시됩니다.
  • ERC-20 시대(녹색): ERC-20 표준은 2015년 말에 최종 확정되었지만, 2017년과 2018년에야 본격적으로 발전했습니다. ERC-20 계약은 2019년에 가장 큰 역사 성장의 원천이 되었습니다.
  • DEX/DeFi 시대(갈색): DEX와 DeFi 계약은 2016년부터 체인 상에 등장했으며, 2017년부터 주목받기 시작했습니다. 그러나 2020년 DeFi 여름이 지나기 전까지는 역사 성장의 최대 카테고리가 되지 않았습니다. DeFi와 DEX 계약은 2021년과 2022년의 일부 기간 동안 역사 성장의 50% 이상을 차지했습니다.
  • Rollup 시대(회색): 2023년 초, L2 Rollup은 메인넷보다 더 많은 거래를 실행하기 시작했습니다. Dencun 이전 몇 달 동안, 이들은 약 2/3의 이더리움 역사 기록을 생성했습니다.

각 시대는 이전보다 더 복잡한 이더리움 사용 패턴을 나타냅니다. 시간이 지남에 따라 복잡성은 이더리움 확장의 한 형태로 볼 수 있으며, 이는 초당 거래량과 같은 간단한 지표로 측정할 수 없습니다.

최근 데이터 월(2024년 4월)에서는 Rollup이 더 이상 대부분의 역사 기록을 생성하지 않고 있습니다. 향후 역사 기록이 DEX와 DeFi에서 발생할지, 아니면 새로운 사용 패턴이 등장할지는 아직 불확실합니다.

blob은 어떻게 되나요?

Dencun 하드 포크는 blob을 도입하여 역사 성장 동력을 크게 변화시켰습니다. 이는 Rollup이 역사 기록 대신 저렴한 blob을 사용하여 데이터를 게시할 수 있도록 허용합니다. 그림 4는 Dencun 업그레이드 전후의 역사 성장률을 확대하여 보여줍니다. 이 그래프는 그림 2와 유사하지만, 각 수직선은 한 달이 아닌 하루를 나타냅니다.

그림 4: Dencun이 역사 성장에 미친 영향

이 그래프에서 우리는 몇 가지 주요 결론을 도출할 수 있습니다:

  • Dencun 이후 Rollup의 역사 성장은 약 2/3 감소했습니다: 대부분의 Rollup은 호출 데이터에서 blob으로 전환되어 생성하는 역사 기록의 양이 크게 줄어들었습니다. 그러나 2024년 4월 현재, 여전히 호출 데이터에서 blob으로 전환되지 않은 Rollup이 있습니다.
  • Dencun 이후 총 역사 성장은 약 1/3 감소했습니다: Dencun은 Rollup의 역사 성장만 감소시켰습니다. 다른 계약 카테고리의 역사 성장은 약간 증가했습니다. Dencun 이후에도 역사 성장은 상태 성장의 8배입니다(자세한 내용은 다음 섹션 참조).

blob이 역사 성장 속도를 낮추었지만, 여전히 이더리움의 새로운 기능입니다. blob이 존재하는 상황에서 역사 성장 속도가 어떤 수준으로 안정될지는 아직 불확실합니다.

얼마나 빠른 역사 성장이 수용 가능한가?

Gas 한도를 높이면 역사 성장률이 증가합니다. 따라서 Gas 한도를 높이는 제안(예: Pump the Gas)은 역사 성장과 각 노드 하드웨어 병목 간의 관계를 고려해야 합니다.

수용 가능한 역사 성장률을 결정하려면, 먼저 현재 노드 하드웨어가 네트워크와 저장 측면에서 얼마나 오랫동안 유지될 수 있는지를 이해해야 합니다. 연결된 하드웨어는 무기한으로 현 상태를 유지할 수 있을 것입니다. Gas 제한을 늘리기 전에 역사 성장률이 Dencun 이전의 정점으로 돌아갈 가능성은 낮기 때문입니다. 그러나 역사 저장 부담은 시간이 지남에 따라 계속 증가할 것입니다. 현재의 저장 전략 하에서 각 노드의 저장 하드 드라이브는 결국 역사 기록으로 가득 차게 될 것입니다. 이는 피할 수 없는 일입니다.

그림 5는 이더리움 노드의 저장 부담이 시간에 따라 어떻게 변화하는지를 보여주며, 향후 3년 동안 저장 부담의 증가를 예측합니다. 예측은 2024년 4월의 성장률을 참조합니다. 향후 사용 패턴이나 Gas 제한의 변화에 따라 이 성장률은 상승하거나 하락할 수 있습니다.

그림 5: 역사 기록, 상태 및 전체 노드 저장 부담의 크기

이 그래프에서 우리는 몇 가지 주요 결론을 도출할 수 있습니다:

  • 역사 기록이 차지하는 저장 공간은 상태의 약 3배입니다. 이 차이는 시간이 지남에 따라 더욱 커질 것입니다. 역사 성장 속도가 상태의 약 8배이기 때문입니다.
  • 1.8 TiB는 임계값으로, 많은 노드가 저장 하드 드라이브를 업그레이드해야 할 것입니다. 2 TB는 일반적인 저장 하드 드라이브 크기로, 1.8 TiB의 사용 가능한 공간만 제공합니다. TB(1조 바이트)와 TiB(= 1024^4 바이트)는 서로 다른 단위입니다. 많은 노드 운영자에게 '진정한' 임계값은 더 낮을 수 있습니다. 왜냐하면 병합 후 검증자는 실행 클라이언트와 함께 합의 클라이언트를 실행해야 하기 때문입니다.
  • 임계값은 2년에서 3년 내에 도달할 것입니다. Gas 제한을 어느 정도 높이면 이 시점에 도달하는 시간이 빨라질 것입니다. 이 임계값에 도달하면 노드 운영자에게 상당한 유지 부담이 발생하며, 추가 하드웨어(예: 300달러의 NVME 드라이브)를 구매해야 할 필요가 있습니다.

상태 데이터와 달리 역사 데이터는 단지 추가적인 것이며, 접근 빈도가 훨씬 낮습니다. 따라서 이론적으로 역사 데이터를 상태 데이터와 분리하여 더 저렴한 저장 매체에 저장할 수 있습니다. 이는 Geth와 같은 일부 클라이언트를 통해 구현할 수 있습니다.

저장 용량 외에도, 네트워크 IO는 역사 성장의 또 다른 주요 제약입니다. 저장 용량과 달리, 네트워크 IO 제약은 단기적으로 노드에 문제를 일으키지 않지만, 이러한 제약은 향후 Gas 제한을 증가시키는 데 중요해질 것입니다.

전형적인 이더리움 노드의 네트워크 용량이 얼마나 많은 역사 성장을 지원할 수 있는지를 이해하려면, 역사 성장과 다양한 네트워크 건강 지표 간의 관계를 알아야 합니다. 예를 들어, 재구성률, 타임슬롯 미스, 최종 미스, 증명 미스, 동기화 위원회 미스 및 블록 제출 지연 등이 있습니다. 이러한 지표의 분석은 이 글의 범위를 초과하지만, 이전의 합의 계층 건강 상태 조사에서 더 많은 정보를 찾을 수 있습니다. 또한, 이더리움 재단의 Xatu 프로젝트는 이러한 분석을 가속화하기 위해 공공 데이터 세트를 구축하고 있습니다.

역사 성장 문제를 어떻게 해결할 것인가?

역사 성장은 상태 성장보다 해결하기 쉬운 문제입니다. 이는 거의 완전히 후보 제안 EIP-4444에 의해 해결될 수 있습니다. 이 EIP는 각 노드가 전체 이더리움 역사 데이터를 저장하는 대신 1년의 역사 데이터만 저장하도록 변경합니다. EIP-4444가 시행되면 데이터 저장은 더 이상 이더리움 확장의 병목 현상이 되지 않으며, 장기적으로 Gas 제한 증가도 제약을 받지 않게 됩니다. EIP-4444는 네트워크의 장기적인 지속 가능성을 위해 필요합니다. 그렇지 않으면 역사 성장 속도가 빠르게 증가하여 정기적으로 네트워크 노드의 하드웨어를 업데이트해야 할 것입니다.

그림 6은 EIP-4444가 향후 3년 동안 각 노드의 저장 부담에 미치는 영향을 보여줍니다. 이는 그림 4와 유사하지만, EIP-4444 시행 후의 저장 부담을 나타내는 더 얕은 선이 추가되었습니다.

그림 6: EIP-4444가 이더리움 노드 저장 부담에 미치는 영향

이 그래프에서 우리는 몇 가지 주요 결론을 도출할 수 있습니다:

  • EIP-4444는 현재의 저장 부담을 절반으로 줄입니다. 저장 부담은 1.2 TiB에서 633 GiB로 줄어듭니다.
  • EIP-4444는 역사 저장 부담을 안정시킵니다. 역사 성장률이 일정하다고 가정하면, 역사 데이터는 생성된 속도로 폐기될 것입니다.
  • EIP-4444 이후, 노드 저장 부담이 오늘날 수준에 도달하는 데는 수년이 걸릴 것입니다. 이는 상태 성장이 저장 부담을 증가시키는 유일한 요소가 될 것이며, 상태의 성장 속도는 역사 성장보다 느리기 때문입니다.

EIP-4444가 시행된 후에도 역사 성장은 일정 정도의 저장 부담을 가져올 것입니다. 노드는 1년의 역사 기록을 저장해야 하기 때문입니다. 그러나 이더리움이 글로벌 규모에 도달하더라도 이 부담은 해결하기 어렵지 않습니다. 역사 기록 저장 방법이 신뢰할 수 있는 것으로 입증되면, EIP-4444의 1년 만료 시간은 몇 개월, 몇 주 또는 그보다 짧게 단축될 수 있습니다.

이더리움의 역사 기록을 어떻게 저장할 것인가?

EIP-4444는 다음과 같은 질문을 제기합니다: 역사 기록이 이더리움 노드에 의해 저장되지 않는다면, 어떻게 저장해야 할까요? 역사 기록은 이더리움의 검증, 정산 및 분석에서 핵심적인 역할을 하므로, 역사 기록을 저장하는 것은 매우 중요합니다. 다행히도 역사 기록 저장은 1/n의 정직한 데이터 제공자만 있으면 되는 간단한 문제입니다. 이는 1/3에서 2/3의 참여자가 정직해야 하는 상태 합의 문제와는 대조적입니다. 노드 운영자는 1) 제네시스 블록 이후의 모든 거래를 재생하고, 2) 이러한 거래가 현재 블록체인 끝에서 동일한 상태 루트를 재현하는지 확인함으로써 역사 데이터 세트의 진위를 검증할 수 있습니다.

역사 기록을 저장하는 방법은 여러 가지가 있습니다.

  • 토렌트 / P2P: 토렌트는 가장 간단하고 신뢰할 수 있는 방법입니다. 이더리움 노드는 정기적으로 일부 역사 기록을 패키징하고 이를 공공 토렌트 파일로 공유할 수 있습니다. 예를 들어, 한 노드는 매 100,000 블록마다 새로운 역사 토렌트 파일을 생성할 수 있습니다. erigon과 같은 노드 클라이언트는 어느 정도 비표준화된 방식으로 이 과정을 수행해왔습니다. 이 과정을 표준화하기 위해 모든 노드 클라이언트는 동일한 데이터 형식, 동일한 매개변수 및 동일한 P2P 네트워크를 사용해야 합니다. 노드는 자신의 저장 및 대역폭 능력에 따라 이 네트워크에 참여할지를 선택할 수 있습니다. 토렌트의 장점은 이미 많은 데이터 도구에서 지원되는 높은 린디 개방 표준을 사용한다는 것입니다.
  • 포털 네트워크: 포털 네트워크는 이더리움 데이터를 호스팅하기 위해 설계된 새로운 네트워크입니다. 이는 토렌트와 유사한 방법이지만, 데이터 검증을 더 쉽게 만드는 몇 가지 추가 기능을 제공합니다. 포털 네트워크의 장점은 이러한 추가 검증 레이어가 경량 클라이언트에 유용성을 제공하여 공유 데이터 세트를 효과적으로 검증하고 쿼리할 수 있게 한다는 것입니다.
  • 클라우드 호스팅: AWS의 S3 또는 Cloudflare의 R2와 같은 클라우드 저장 서비스는 역사 기록을 저장하는 저렴하고 고성능의 선택지를 제공합니다. 그러나 이 방법은 이러한 클라우드 서비스가 항상 암호화폐 데이터를 호스팅할 의향과 능력이 있다는 보장이 없기 때문에 더 많은 법적 위험과 비즈니스 운영 위험을 동반합니다.

나머지 구현 도전 과제는 기술적 도전 과제가 아닌 사회적 도전 과제가 더 많습니다. 이더리움 커뮤니티는 각 노드 클라이언트에 이를 직접 통합하기 위한 구체적인 구현 세부 사항을 조정해야 합니다. 특히, 제네시스 블록부터 완전 동기화(스냅샷 동기화가 아닌)를 수행하려면 이더리움 노드가 아닌 역사 기록 제공자로부터 역사 기록을 검색해야 합니다. 이러한 변경 사항은 기술적으로 하드 포크를 필요로 하지 않으므로, 이들은 이더리움의 다음 하드 포크인 Pectra보다 더 빨리 구현될 수 있습니다.

모든 이러한 역사 저장 방법은 L2가 메인넷에 게시한 blob 데이터를 저장하는 데에도 사용할 수 있습니다. 역사 저장과 비교할 때, blob 저장은 1) 총 데이터 양이 훨씬 더 많기 때문에 더 어렵고; 2) 메인넷 역사 재생에 필요하지 않기 때문에 덜 중요합니다. 그러나 각 L2가 자신의 역사를 재생하는 데 있어 blob 저장은 여전히 필요합니다. 따라서 어떤 형태의 blob 저장은 전체 이더리움 생태계에 매우 중요합니다. 또한, L2가 강력한 blob 저장 인프라를 개발하면 L1 역사 데이터를 쉽게 저장할 수 있을 것입니다.

EIP-4444 이전과 이후의 다양한 노드 구성 저장 데이터 세트를 직접 비교하는 것이 매우 유용할 것입니다. 그림 7은 다양한 이더리움 노드 유형의 저장 부담을 보여줍니다. 상태 데이터는 계정과 계약, 역사 데이터는 블록과 거래, 아카이브 데이터는 선택적 데이터 인덱스의 집합입니다. 이 표의 바이트 수는 최근의 reth 스냅샷을 기준으로 하지만, 다른 노드 클라이언트의 숫자도 대체로 비슷할 것입니다.

그림 7: 다양한 이더리움 노드 유형의 저장 부담

다시 말해,

  • 아카이브 노드는 상태 데이터와 역사 데이터 및 아카이브 데이터를 저장합니다. 누군가가 역사 체인 상태를 쉽게 쿼리할 수 있기를 원할 때 아카이브 노드를 사용할 수 있습니다.
  • 전체 노드는 역사 데이터와 상태 데이터만 저장합니다. 현재 대부분의 노드는 전체 노드입니다. 전체 노드의 저장 부담은 아카이브 노드의 약 절반입니다.
  • EIP-4444 이후의 전체 노드는 상태 데이터와 최근 1년의 역사 데이터만 저장합니다. 이는 노드의 저장 부담을 1.2 TiB에서 633 GiB로 줄이고, 역사 데이터의 저장 공간을 안정 상태 값으로 만듭니다.
  • 무상태 노드, 즉 '경량 노드'는 어떤 데이터 세트도 저장하지 않으며, 체인의 끝에서 즉시 검증할 수 있습니다. Verkle 시도 또는 기타 상태 약속 계획이 이더리움에 추가되면 이러한 노드 유형이 가능해집니다.

마지막으로, 역사 성장률을 제한하는 추가 EIP가 몇 가지 있으며, 이는 현재 성장률에만 적응하는 것이 아닙니다. 이는 단기적으로 네트워크 IO 제약 내에서 유지하는 데 도움이 되며, 장기적으로 저장 제약 내에서 유지하는 데 도움이 됩니다. EIP-4444가 네트워크의 장기적인 지속 가능성을 위해 여전히 필요하지만, 이러한 다른 EIP는 이더리움이 미래에 더 효율적으로 확장하는 데 도움이 될 것입니다:

  • EIP-7623: 호출 데이터를 재가격 책정하여 특정 호출 데이터가 과도한 거래를 더욱 비싸게 만듭니다. 이러한 사용 패턴을 더 비싸게 만들면 일부가 호출 데이터에서 blob으로 전환되도록 강제할 것입니다. 이는 역사 성장률을 낮출 것입니다.
  • EIP-4488: 각 블록에 포함될 수 있는 호출 데이터의 총량에 제한을 둡니다. 이는 역사 기록의 성장 속도에 더 엄격한 제한을 가할 것입니다.

이러한 EIP는 EIP-4444보다 구현이 더 쉬우므로, 이들은 EIP-4444가 생산에 투입되기 전에 단기적인 임시 방편으로 사용될 수 있습니다.

결론

이 글의 목적은 데이터를 통해 1) 역사 성장의 작동 방식과 2) 이 문제를 해결하는 방법을 이해하는 것입니다. 이 글의 많은 데이터는 전통적인 방식으로 얻기 어려우므로, 우리는 이러한 데이터를 공개하여 역사 성장 문제에 대한 새로운 통찰을 제공하고자 합니다.

역사 성장은 이더리움 확장의 병목 현상으로 충분한 주목을 받지 못하고 있습니다. Gas 한도를 늘리지 않더라도, 이더리움이 현재 역사 기록을 저장하는 관행은 많은 노드가 몇 년 내에 하드웨어를 업그레이드하도록 강제할 것입니다. 다행히도, 이는 해결하기 어려운 문제가 아닙니다. EIP-4444에는 이미 명확한 해결책이 있습니다. 우리는 이 EIP의 시행을 가속화하여 미래의 Gas 한도 증가를 위한 여지를 마련해야 한다고 생각합니다.

체인캐처(ChainCatcher)는 독자들에게 블록체인을 이성적으로 바라보고, 리스크 인식을 실제로 향상시키며, 다양한 가상 토큰 발행 및 조작에 경계해야 함을 상기시킵니다. 사이트 내 모든 콘텐츠는 시장 정보나 관련 당사자의 의견일 뿐이며 어떠한 형태의 투자 조언도 제공하지 않습니다. 만약 사이트 내에서 민감한 정보를 발견하면 “신고하기”를 클릭하여 신속하게 처리할 것입니다.
체인캐처 혁신가들과 함께하는 Web3 세상 구축