Haskell을 사용하여 FunC를 FunCtional로 전환: Serokell이 Telegram 블록체인 대회에서 우승한 방법

텔레그램이라는 말을 들어보셨을 겁니다. Ton 블록체인 플랫폼 출시를 앞두고 있습니다.. 하지만 얼마 전 텔레그램에서 전해진 소식을 놓치셨을 수도 있습니다. 대회를 발표했다 이 플랫폼에 대한 하나 이상의 스마트 계약 구현을 위해.

대규모 블록체인 프로젝트 개발에 대한 광범위한 경험을 보유한 Serokell 팀은 옆으로 설 수 없었습니다. 우리는 XNUMX명의 직원을 대회에 위임했고, XNUMX주 후 그들은 섹시 카멜레온(Sexy Chameleon)이라는 겸손한 별명으로 대회에서 XNUMX위를 차지했습니다. 이 기사에서는 그들이 어떻게했는지에 대해 이야기하겠습니다. 앞으로 XNUMX분 안에 최소한 흥미로운 이야기를 읽고, 기껏해야 업무에 적용할 수 있는 유용한 내용을 찾을 수 있기를 바랍니다.

하지만 약간의 맥락부터 시작해 보겠습니다.

경쟁과 그 조건

따라서 참가자의 주요 임무는 제안된 스마트 계약 중 하나 이상을 구현하고 TON 생태계를 개선하기 위한 제안을 작성하는 것이었습니다. 대회는 24월 15일부터 15월 XNUMX일까지 진행됐으며 결과는 XNUMX월 XNUMX일에야 발표됐다. 이 기간 동안 Telegram이 Telegram의 VoIP 통화 품질을 테스트하고 평가하기 위해 C++ 애플리케이션 설계 및 개발에 관한 콘테스트 결과를 개최하고 발표했다는 점을 고려하면 꽤 오랜 시간이 걸렸습니다.

우리는 주최측이 제안한 목록에서 두 개의 스마트 계약을 선택했습니다. 그 중 하나는 TON과 함께 배포된 도구를 사용했고, 두 번째는 엔지니어가 TON용으로 특별히 개발하고 Haskell에 내장된 새로운 언어로 구현했습니다.

함수형 프로그래밍 언어를 선택한 것은 우연이 아닙니다. 우리의 기업 블로그 우리는 함수형 언어의 복잡성이 엄청나게 과장되었다고 생각하는 이유와 일반적으로 객체지향 언어보다 함수형 언어를 선호하는 이유에 대해 자주 이야기합니다. 그건 그렇고, 그것은 또한 포함되어 있습니다 이 기사의 원본.

우리가 참여하기로 결정한 이유는 무엇입니까?

간단히 말해서, 우리의 전문 분야는 특별한 기술이 필요하고 종종 IT 커뮤니티에 과학적 가치가 있는 비표준적이고 복잡한 프로젝트이기 때문입니다. 우리는 오픈소스 개발을 강력히 지지하고 대중화에 힘쓰고 있으며, 컴퓨터 과학 및 수학 분야의 러시아 유수의 대학들과도 협력하고 있습니다.

경쟁이라는 흥미로운 과제와 우리가 사랑하는 텔레그램 프로젝트에 참여하는 것은 그 자체로 훌륭한 동기 부여가 되었지만 상금은 추가적인 인센티브가 되었습니다. 🙂

TON 블록체인 연구

우리는 블록체인, 인공 지능 및 기계 학습의 새로운 개발을 면밀히 모니터링하고 우리가 작업하는 각 영역에서 하나의 중요한 릴리스를 놓치지 않으려고 노력합니다. 따라서 대회가 시작될 무렵 우리 팀은 이미 TON 백서. 그러나 TON 작업을 시작하기 전에 우리는 플랫폼의 기술 문서와 실제 소스 코드를 분석하지 않았기 때문에 첫 번째 단계는 매우 분명했습니다. 온라인으로 과 프로젝트 저장소.

대회가 시작될 때쯤에는 코드가 이미 공개되었으므로 시간을 절약하기 위해 우리는 다음과 같은 가이드나 요약을 찾아보기로 결정했습니다. 사용자 별. 불행히도 이것은 결과를 제공하지 못했습니다. Ubuntu에서 플랫폼을 조립하는 지침 외에 다른 자료를 찾지 못했습니다.

문서 자체는 잘 조사되었지만 일부 영역에서는 읽기가 어려웠습니다. 종종 우리는 특정 지점으로 돌아가 추상적 아이디어에 대한 높은 수준의 설명에서 낮은 수준의 구현 세부 사항으로 전환해야 했습니다.

사양에 구현에 대한 자세한 설명이 전혀 포함되어 있지 않으면 더 쉬울 것입니다. 가상 머신이 스택을 어떻게 표현하는지에 대한 정보는 TON 플랫폼에 대한 스마트 계약을 생성하는 개발자를 돕는 것보다 주의를 산만하게 할 가능성이 더 높습니다.

Nix: 프로젝트를 하나로 합치기

Serokell에서 우리는 열렬한 팬입니다. 거절하다. 우리는 그들과 함께 프로젝트를 수집하고 다음을 사용하여 배포합니다. 닉스옵스, 모든 서버에 설치됩니다. 닉스OS. 덕분에 우리의 모든 빌드는 재현 가능하며 Nix를 설치할 수 있는 모든 운영 체제에서 작동합니다.

그래서 우리는 만드는 것부터 시작했습니다. TON 어셈블리용 표현식이 포함된 Nix 오버레이. 도움을 받으면 TON 컴파일이 최대한 간단해집니다.

$ cd ~/.config/nixpkgs/overlays && git clone https://github.com/serokell/ton.nix
$ cd /path/to/ton/repo && nix-shell
[nix-shell]$ cmakeConfigurePhase && make

종속성을 설치할 필요는 없습니다. NixOS, Ubuntu, macOS 등 무엇을 사용하든 Nix는 마법처럼 모든 것을 대신해 드립니다.

TON 프로그래밍

TON 네트워크의 스마트 계약 코드는 TON 가상 머신(TVM)에서 실행됩니다. TVM은 대부분의 다른 가상 머신보다 더 복잡하며 매우 흥미로운 기능을 가지고 있습니다. 연속 и 데이터 링크.

게다가 TON의 사람들은 세 가지 새로운 프로그래밍 언어를 만들었습니다.

오십 다음과 유사한 범용 스택 프로그래밍 언어입니다. 앞으로. 그의 초능력은 TVM과 상호작용하는 능력이다.

펀씨 다음과 유사한 스마트 계약 프로그래밍 언어입니다. C 그리고 다른 언어인 Fift Assembler로 컴파일됩니다.

다섯 번째 어셈블러 — TVM용 바이너리 실행 코드를 생성하기 위한 다섯 번째 라이브러리입니다. 다섯 번째 어셈블러에는 컴파일러가 없습니다. 이것 eDSL(임베디드 도메인 특정 언어).

우리의 경쟁은 작동합니다

마지막으로, 우리의 노력의 결과를 살펴볼 시간입니다.

비동기 결제 채널

결제 채널은 두 명의 사용자가 블록체인 외부로 결제를 보낼 수 있도록 하는 스마트 계약입니다. 결과적으로 비용(수수료 없음)뿐만 아니라 시간(다음 블록이 처리될 때까지 기다릴 필요가 없음)도 절약됩니다. 지불 금액은 원하는 만큼 소액으로, 필요한 만큼 자주 지불할 수 있습니다. 이 경우 최종 정산의 공정성은 스마트 컨트랙트에 의해 보장되므로 당사자들은 서로를 신뢰할 필요가 없다.

우리는 문제에 대한 매우 간단한 해결책을 찾았습니다. 두 당사자는 서명된 메시지를 교환할 수 있으며, 각 메시지에는 각 당사자가 지불한 전체 금액인 두 개의 숫자가 포함되어 있습니다. 이 두 숫자는 다음과 같이 작동합니다. 벡터 시계 전통적인 분산 시스템에서는 트랜잭션에 "이전에 발생한" 순서를 설정합니다. 이 데이터를 사용하면 계약서에서 발생할 수 있는 모든 충돌을 해결할 수 있습니다.

사실 이 아이디어를 구현하려면 숫자 하나면 충분하지만, 이렇게 하면 좀 더 편리한 사용자 인터페이스를 만들 수 있기 때문에 두 숫자를 모두 남겨두었습니다. 또한 각 메시지에 결제 금액을 포함하기로 결정했습니다. 그것이 없으면 어떤 이유로 메시지가 손실되면 모든 금액과 최종 계산이 정확하더라도 사용자는 손실을 인식하지 못할 수 있습니다.

우리의 아이디어를 테스트하기 위해 우리는 간단하고 간결한 결제 채널 프로토콜을 사용하는 예를 찾았습니다. 놀랍게도 우리는 단 두 가지만 발견했습니다.

1. 기술 단방향 채널의 경우에만 유사한 접근 방식입니다.
2. 지도 시간, 이는 우리와 동일한 아이디어를 설명하지만 일반적인 정확성 및 충돌 해결 절차와 같은 많은 중요한 세부 사항을 설명하지 않습니다.

프로토콜의 정확성에 특별한 주의를 기울이면서 프로토콜을 자세히 설명하는 것이 합리적이라는 것이 분명해졌습니다. 여러 번의 반복 끝에 사양이 준비되었으며 이제 여러분도 그렇게 할 수 있습니다. 그녀를 봐.

우리는 FunC에서 계약을 구현했으며, 주최자의 권장에 따라 계약과 상호 작용하기 위한 명령줄 유틸리티를 Fift에서 완전히 작성했습니다. CLI에 다른 언어를 선택할 수도 있었지만 Fit이 실제로 어떻게 작동하는지 알아보고 싶었습니다.

솔직히 말해서, Fift와 작업한 후에 우리는 개발된 도구와 라이브러리를 통해 널리 사용되고 활발하게 사용되는 언어보다 이 언어를 선호할 만한 설득력 있는 이유를 찾지 못했습니다. 스택 기반 언어로 프로그래밍하는 것은 스택에 있는 내용을 계속 머릿속에 유지해야 하는데 컴파일러가 이에 대해 도움을 주지 않기 때문에 매우 불쾌합니다.

따라서 우리 의견으로는 Fift의 존재에 대한 유일한 정당성은 Fift Assembler의 호스트 언어로서의 역할입니다. 그러나 본질적으로 유일한 목적을 위해 새로운 언어를 개발하는 것보다 TVM 어셈블러를 기존 언어에 내장하는 것이 더 낫지 않을까요?

TVM 하스켈 eDSL

이제 두 번째 스마트 계약에 대해 이야기할 차례입니다. 우리는 다중 서명 지갑을 개발하기로 결정했지만 FunC에서 또 다른 스마트 계약을 작성하는 것은 너무 지루할 것입니다. 우리는 약간의 풍미를 더하고 싶었고 그것이 우리만의 TVM용 어셈블리 언어였습니다.

Fift Assembler와 마찬가지로 새로운 언어가 내장되어 있지만 Fift 대신 Haskell을 호스트로 선택하여 고급 유형 시스템을 최대한 활용할 수 있었습니다. 작은 오류로 인해 발생하는 비용이 매우 높을 수 있는 스마트 계약을 사용할 때 정적 타이핑이 큰 이점이라고 생각합니다.

Haskell에 내장된 TVM 어셈블러가 어떤 모습인지 보여주기 위해 표준 지갑을 구현했습니다. 주의해야 할 몇 가지 사항은 다음과 같습니다.

• 이 계약은 하나의 기능으로 구성되지만 원하는 만큼 사용할 수 있습니다. 호스트 언어(예: Haskell)로 새 기능을 정의할 때 eDSL을 사용하면 해당 기능이 TVM에서 별도의 루틴이 되도록 할지 아니면 호출 시점에 단순히 인라인으로 삽입할지 선택할 수 있습니다.
• Haskell과 마찬가지로 함수에는 컴파일 타임에 확인되는 유형이 있습니다. eDSL에서 함수의 입력 유형은 함수가 기대하는 스택 유형이고, 결과 유형은 호출 후에 생성될 스택 유형입니다.
• 코드에 주석이 있습니다 stacktype, 콜 포인트에서 예상되는 스택 유형을 설명합니다. 원래 지갑 계약에서는 주석에 불과했지만 eDSL에서는 실제로 코드의 일부이며 컴파일 타임에 확인됩니다. 이는 코드가 변경되고 스택 유형이 변경되는 경우 개발자가 문제를 찾는 데 도움이 되는 문서 또는 설명 역할을 할 수 있습니다. 물론 이러한 주석은 TVM 코드가 생성되지 않으므로 런타임 성능에 영향을 주지 않습니다.
• 아직 XNUMX주 만에 작성된 프로토타입이기 때문에 아직 프로젝트에서 해야 할 일이 많이 남아있습니다. 예를 들어 아래 코드에 표시되는 클래스의 모든 인스턴스는 자동으로 생성되어야 합니다.

eDSL에서 다중서명 지갑 구현은 다음과 같습니다.

main :: IO ()
main = putText $ pretty $ declProgram procedures methods
  where
    procedures =
      [ ("recv_external", decl recvExternal)
      , ("recv_internal", decl recvInternal)
      ]
    methods =
      [ ("seqno", declMethod getSeqno)
      ]

data Storage = Storage
  { sCnt :: Word32
  , sPubKey :: PublicKey
  }

instance DecodeSlice Storage where
  type DecodeSliceFields Storage = [PublicKey, Word32]
  decodeFromSliceImpl = do
    decodeFromSliceImpl @Word32
    decodeFromSliceImpl @PublicKey

instance EncodeBuilder Storage where
  encodeToBuilder = do
    encodeToBuilder @Word32
    encodeToBuilder @PublicKey

data WalletError
  = SeqNoMismatch
  | SignatureMismatch
  deriving (Eq, Ord, Show, Generic)

instance Exception WalletError

instance Enum WalletError where
  toEnum 33 = SeqNoMismatch
  toEnum 34 = SignatureMismatch
  toEnum _ = error "Uknown MultiSigError id"

  fromEnum SeqNoMismatch = 33
  fromEnum SignatureMismatch = 34

recvInternal :: '[Slice] :-> '[]
recvInternal = drop

recvExternal :: '[Slice] :-> '[]
recvExternal = do
  decodeFromSlice @Signature
  dup
  preloadFromSlice @Word32
  stacktype @[Word32, Slice, Signature]
  -- cnt cs sign

  pushRoot
  decodeFromCell @Storage
  stacktype @[PublicKey, Word32, Word32, Slice, Signature]
  -- pk cnt' cnt cs sign

  xcpu @1 @2
  stacktype @[Word32, Word32, PublicKey, Word32, Slice, Signature]
  -- cnt cnt' pk cnt cs sign

  equalInt >> throwIfNot SeqNoMismatch

  push @2
  sliceHash
  stacktype @[Hash Slice, PublicKey, Word32, Slice, Signature]
  -- hash pk cnt cs sign

  xc2pu @0 @4 @4
  stacktype @[PublicKey, Signature, Hash Slice, Word32, Slice, PublicKey]
  -- pubk sign hash cnt cs pubk

  chkSignU
  stacktype @[Bool, Word32, Slice, PublicKey]
  -- ? cnt cs pubk

  throwIfNot SignatureMismatch
  accept

  swap
  decodeFromSlice @Word32
  nip

  dup
  srefs @Word8

  pushInt 0
  if IsEq
  then ignore
  else do
    decodeFromSlice @Word8
    decodeFromSlice @(Cell MessageObject)
    stacktype @[Slice, Cell MessageObject, Word8, Word32, PublicKey]
    xchg @2
    sendRawMsg
    stacktype @[Slice, Word32, PublicKey]

  endS
  inc

  encodeToCell @Storage
  popRoot

getSeqno :: '[] :-> '[Word32]
getSeqno = do
  pushRoot
  cToS
  preloadFromSlice @Word32

eDSL 및 다중 서명 지갑 계약의 전체 소스 코드는 다음에서 찾을 수 있습니다. 이 저장소. 기타 자세히 말했다 내장 언어에 대해 우리 동료 Georgy Agapov가 말했습니다.

대회와 TON에 대한 결론

우리 작업에는 총 380시간이 걸렸습니다(문서 숙지, 회의 및 실제 개발 포함). 경쟁 프로젝트에는 CTO, 팀 리더, 블록체인 플랫폼 전문가, Haskell 소프트웨어 개발자 등 XNUMX명의 개발자가 참여했습니다.

해커톤의 정신, 긴밀한 팀워크, 신기술 측면에 빠르게 몰입해야 하는 필요성은 항상 흥미로웠기 때문에 우리는 어려움 없이 콘테스트에 참가할 수 있는 리소스를 찾았습니다. 제한된 자원에서 최대의 결과를 얻기 위해 잠 못 이루는 여러 밤은 귀중한 경험과 훌륭한 추억으로 보상됩니다. 또한, 이러한 작업을 수행하는 것은 항상 회사 프로세스에 대한 좋은 테스트입니다. 제대로 작동하는 내부 상호 작용 없이는 진정으로 괜찮은 결과를 얻는 것이 극히 어렵기 때문입니다.

가사는 제쳐두고, 우리는 TON 팀이 쏟은 작업량에 깊은 인상을 받았습니다. 그들은 복잡하고 아름답고 가장 중요한 작업 시스템을 구축했습니다. TON은 큰 잠재력을 지닌 플랫폼임이 입증되었습니다. 그러나 이 생태계가 발전하려면 블록체인 프로젝트에서의 사용과 개발 도구 개선 측면에서 훨씬 더 많은 작업이 수행되어야 합니다. 우리는 이제 이 과정에 참여하게 된 것을 자랑스럽게 생각합니다.

이 기사를 읽은 후에도 여전히 질문이 있거나 TON을 사용하여 문제를 해결하는 방법에 대한 아이디어가 있다면, 우리에게 편지를 보내세요 — 우리는 우리의 경험을 기꺼이 공유할 것입니다.

출처 : habr.com