@jolestar에서

어제 와모 치앙마이 빌더데이 공유세션에서 "반동질자산의 관점에서 명문을 바라보다"라는 주제로 명문에 대해 이야기를 나눴습니다.

기술적인 측면에서 볼 때 비문은 단순하고 투박한데 기술자들이 처음 봤을 때 물음표 표현이 있어야 하는데 이게 뭐지?

그러나 최근 스마트 계약의 비문을 분석한 경험을 통해 실제로는 SFT(반대체 자산)로 이해될 수 있다는 결론을 내렸습니다.

원래 Ordinals Inscription은 content_type, content를 포함한 고유한 ID를 가지며 어떤 데이터 유형에도 삽입될 수 있는 NFT의 표현으로 이해될 수 있습니다. BRC20 프로토콜은 JSON을 콘텐츠에 포함하고 FT를 정의합니다. NFT에서의 FT는 실제로 SFT의 전형적인 표현으로, 모든 사람들은 인스크립션을 사고 팔 때 "조각"을 단위로 사용하는 데 익숙합니다.

SFT의 사용 시나리오는 무엇입니까? 사실 지난 DeFi 기간 동안 모두가 이에 대해 심층적인 연구를 했습니다. 예를 들어 게임소품을 표현할 때 사용되며, 중간에 있는 FT의 가치는 희소성을 표현할 수도 있고, 채권, 쿠폰, 각종 지폐 등을 표현할 수도 있습니다. 그러나 마지막 사이클에서는 그 특성이 충분히 활용되지 않았으며 SFT 유형의 자산이 많이 생성되지 않았습니다. 이제 비문이 인기를 끌면서 이러한 유형의 자산이 완전히 생성되었습니다. 어떻게 사용합니까?

현재 비문의 확장성 딜레마

비문을 SFT로 활용하려면 이에 대한 사용 시나리오를 만들고 비문 프로토콜을 확장해야 합니다. 일부 팀은 BRC20에 더 많은 작업 지침을 추가하는 등 비문 프로토콜을 확장하여 이를 달성하려고 시도했습니다. 그러나 비문 프로토콜이 시장에서 널리 수용되면 여러 인덱서가 이를 구현해야 하며, 프로토콜을 확장하려면 여러 인덱서가 오프체인 합의에 도달하고 합의 업그레이드를 달성해야 합니다. L1 합의 업그레이드 분명히 확장성 요구 사항을 충족하는 것은 어렵습니다.

이러한 확장성 요구 사항에 대응하여 업계에서는 실제로 스마트 계약이라는 성숙한 솔루션을 개발했습니다. 블록체인의 스마트 계약 가상 머신 모델은 전체 소프트웨어 엔지니어링 커뮤니티에서 탐색한 가장 확장성이 뛰어난 모델입니다. 따라서 현재 두 가지 솔루션이 있습니다. 1. 인덱서에 스마트 계약을 도입합니다. 2. 스마트 계약을 통해 비문을 표현합니다.

인덱서에 스마트 계약 도입

인덱서에 스마트 계약을 도입하는 것을 스마트 인덱서 또는 모듈형 블록체인의 실행 계층이라고 부를 수 있습니다. Inscription 모델은 DA First의 소버린 롤업으로 이해될 수 있으며 L1을 DA로 사용하고 시퀀서를 도입하지 않고 L1의 블록을 통해 트랜잭션을 직접 정렬하며 인덱서는 자연스럽게 실행 계층으로 이해될 수 있습니다. 나는 "비문이 버그인가, 기능인가?"라는 기사에서 이 모델에 대해 논의했습니다. 이에 대한 설명은 https://twitter.com/jolestar/status/1732711942563959185에 나와 있습니다. Rooch도 이 방향을 모색하고 있습니다. 구체적인 계획은 "비트코인의 레이어 2를 어떻게 구현해야 합니까?"를 참조하세요. 》https://twitter.com/jolestar/status/1717358817992995120.

우리는 Bitcoin Plants라는 이 시나리오에 대한 예제 게임을 구축하고 있습니다. Rooch에는 전체 비트코인 ​​상태가 있으므로 스마트 계약에서 Inscriptions의 Inscription을 읽을 수 있습니다. 사용자는 게임에서 Inscription을 씨앗으로 사용하여 식물을 키울 수 있습니다. 이 식물에는 사용자가 정기적으로 물을 주어야 합니다. 그러면 열매를 맺을 수 있습니다. 이 식물은 Inscription에 귀속되어 있으며, 사용자가 비트코인으로 Inscription을 전송하면 식물도 전송됩니다. 이 간단한 예는 계층에서 스마트 계약을 실행하여 L1 비문에 대한 사용 시나리오를 생성하는 방법을 보여줍니다. 자세한 내용은 github 문제 https://github.com/rooch-network/rooch/issues/1214를 참조하세요.

또, 이쓰스크립션스가 패싯 가상머신을 구축하고 있는 것도 비슷한 루트로 본 적이 있는데, 업계 친구들도 이런 방향을 본 것 같습니다.

스마트 계약을 통한 비문 표현

비트코인에 스마트 계약이 없다면 개발자들은 JSON을 새기는 방법을 찾아냈습니다. 다른 스마트 계약 체인이 여전히 JSON을 작성하는 이유는 무엇입니까? 가장 이해하기 어려운 점은 Rollup L2에서 JSON을 작성할 때 해당 JSON이 결국 L1으로 롤업될 예정인데 왜 L2에 작성합니까? L2는 자연스럽게 L1 비문의 인덱서가 되어야 하지 않나요? 아직도 비문 인덱서가 필요합니까? 그러나 이것조차도 인스크립션 플레이에 대한 사용자의 열정을 막을 수는 없으며 많은 L2 플레이어가 실패했습니다. 그래서 그것에 대해 생각한 후, 나는 비문에서 밝혀진 몇 가지 사실을 요약했습니다.

1. 반 대체 가능한 자산이고 유동성이 FT만큼 좋지는 않지만 시장 초기에는 이것이 장점입니다.

2. 각 체인의 자산 발행 임계값은 FT보다 낮고 인지 비용도 낮습니다. 각 체인에서 자산을 발행하려면 일반적으로 스마트 계약 배포가 필요하며 식별은 주로 계약 주소를 통해 이루어지므로 초보자에게는 어렵습니다. 이러한 비문의 물결은 기본적으로 이 임계값을 가장 낮은 수준으로 낮췄습니다.

3. 비트코인의 공정한 발행 모델은 가스를 통해 채굴자를 임대하는 PoW 발행 모델로 이해될 수 있습니다.

그렇다면 스마트 계약을 사용하여 위의 특성을 가진 비문 프로토콜을 구현하는 것은 어떨까요? 그래서 이번 주에는 Move를 사용하여 Movementscriptions 프로토콜을 구현해 보았습니다.

첫째, Move를 통해 표현된 준 대체 가능한 자산 프로토콜입니다. Move의 데이터 구조 기반 자산 표현은 이 프로토콜을 표현하는 데 이상적입니다.

1. 글로벌 고유 이름인 Tick을 사용하여 유형을 표현하며, BRC20을 참고하여 KISS 원리를 따르며 간단하고 직관적입니다.

2. Value는 FT의 잔액을 표현하거나 NFT의 핵심값을 표현하는데 사용될 수 있습니다.

3. 메타데이터는 모든 유형의 데이터에 추가될 수 있습니다.

둘째, PoW를 통한 자산분배를 지원합니다. 배포자는 자산의 보다 공정하고 분산된 배포를 보장하기 위해 난이도를 지정하여 난이도를 설정할 수 있습니다. 다른 체인의 가스가 너무 낮기 때문에 가스를 태워서 마녀의 공격을 막는 것은 어렵습니다.

3. 메타데이터는 모든 유형의 데이터에 추가될 수 있습니다.

둘째, PoW를 통한 자산분배를 지원합니다. 배포자는 자산의 보다 공정하고 분산된 배포를 보장하기 위해 난이도를 지정하여 난이도를 설정할 수 있습니다. 다른 체인의 가스가 너무 낮기 때문에 가스를 태워서 마녀의 공격을 막는 것은 어렵습니다.

스마트 컨트랙트를 통해 실현되는 인스크립션을 스마트 인스크립션이라고 부르는데요, 이제 드디어 스마트 컨트랙트가 필요한 수준으로 인스크립션이 진화하는 시대가 왔습니다. 이러한 비문은 당연히 스마트 계약의 상태이며 인덱서에 의존하지 않으며 FOCG와 같은 다양한 응용 시나리오와 쉽게 결합할 수 있습니다. 이 실험에 관심이 있는 친구들은 팔로우할 수 있습니다

@이동 설명

및 github https://github.com/movescriptions/movescriptions. 현재 Rooch 버전의 계약은 초기 완료되었으며 PoW 배포도 구현되었으며 다른 Move Chain 버전도 진행 중입니다.

개발자를 위한 Inscription의 영감

인스크립션(Inscription)은 비트코인에서 무작위 시도로 시작되어 현재 모든 퍼블릭 체인을 휩쓸고 있습니다.간단하고 투박하지만 매우 중요합니다. 미래는 불분명하고 이에 대한 견해에는 큰 차이가 있지만, 이는 또한 시장의 흥미로운 부분이며, 차이가 발생하는 곳에 기회가 항상 있습니다. 따라서 임의성을 추가해 보면 개발자가 조치를 취할 수 있으므로 사용자가 사용법을 모르는 JSON을 대량으로 각인시키는 대신 스마트 계약과 결합하는 것이 좋습니다. 조합이 성공한다면 FOGC와 AW 출시의 발판이 될 수도 있는데 이에 대해서는 다음 글에서 다루겠습니다.