솔라나 vs 이더리움

이더리움 네트워크와 다른 점이 많아서 헷갈려, 나만의 정리 해봄

lamport

• SOL-lamport와 ether-wei의 관계가 비슷하다고 보면 됨
  lamport = 0.000000001 SOL.

program

스마트 컨트랙트를 이더리움에선 보통 contract라고 하는데,
솔라나는 이를 program이라 함

program은 상태를 보유하지 않음

이더리움은 contract가 상태를 가질 수 있었다.
근데 솔라나는 그게 안됨. 대신 program은 state account를 통해 state를 가질 수 있음

account

account는 데이터 저장 공간이라고 보면 될 듯 하다.
근데 이 데이터 저장 공간을 유지하려면 rent 비용을 내야됨
이 rent 비용을 면제 받기 위해서는 rent exempt minimum을 넣어두어야 함
안그러면 매 epoch마다 공간 사용료를 지불해야한다.

A stake account is like any other account in Solana and thus you either:
a) Keep your balance above a rent exempt minimum, or
b) Pay rent
Most people do not want to pay rent, which would be SOL paid every single epoch just to retain the account. So most people for most purposes always create accounts with at least the rent exempt minimum.
That means that to create a stake account, you must put at least 0.00228288 SOL into it to satisfy the rent-exempt minimum.
However, none of that earns rewards for stake. Only the SOL in an account above and beyond the rent exempt minimum earns rewards.
Therefore:
-> The minimum you can 'stake' is 0.00228288 SOL
-> And at that minimum you will earn 0
The minimum you can stake to actually earn rewards is:
.002282881 SOL
And then you will earn rewards on 0.000000001 SOL.
So yes, you can stake $100 worth, which is much more than the rent-exempt minimum!

또한, 각 Account들은 Owner가 있으며, Owner만이 data를 account의 데이터를 바꿀 수 있다.
이 때 Program만이 Account들의 Owner가 될 수 있다.
Program이 여러 Account를 소유하는 것이 솔라나의 중요 개념인 듯
심지어 사용자의 SOL Account마저 system program의 소유이다.
이 program이 SOL transaction을 처리해주는 것

아직까진 솔라나의 모든 상황은 프로그램에 의해 결정되는 것으로 보임

더 나아가서, 변경될 Account들은 entrypoint에 전달되어야 한다. 병렬 처리를 위해서인데, 같은 account를 동시에 만지지 않기 위해서 앞으로 조작될 writable account들을 미리 알고 있어야 한다. 따라서 entrypoint에 미리 전달되지 않은 account에 조작이 가해지면 transaction은 실패 된다.

코드 구조

일반적인 솔라나 프로그램 구조이다

Flow는 다음과 같다.
1. 누군가 entrypoint를 호출한다.
2. entrypoint는 instruction_data를 processor에게 넘긴다.
3. processor는 instruction.rs에게  instruction_data 해독을 부탁한다.
4. 해독이 완료되면, data에 따라 processor는 무엇을 진행할지 결정한다.
5. 필요하다면, processor는 state.rs를 이용해 entrypoint로 넘어온 account의 state를 해독한다.

escrow program flow

Alice와 Bob이 토큰 X,Y를 교환한다.
이 때 그림을 보면 Program들이 여러 Account를 소유하고 있는 것을 볼 수 있다.

그런데 여기서,
Token Program이 token account를 소유하고 있는데,
Alice main account는 token account X에 어떻게 연결되어 하는걸까?
이를 이해하기 위해서는 Token Program을 더 봐야함

token program

일단 모든 token account에 대한 key 관리를 alice가 해야한다면 유지가 어려움
만약 500개의 토큰을 보유하기 위해서, 500개의 key 관리를 한다 생각하면 벌써 어지러움
하지만 alice 개인키 하나로 다 대응할 수 있다면 어떨까?
Token Program은 바로 이 방식으로 위의 문제를 해결해줌

그림을 보면 Token Program과 Alice main acc 둘다 Alice token acc X를 own하고 있다.
Token Program은 자신의 state 안에 Account Struct으로 보관하고 있는 것이고,
그 Struct안의 Public 키에 Alice를 적어줌으로써 Alice main acc가 own하게 되는 것 같음

이렇게 되면 Token Program의 개인키는 의미가 없어지고,
송금과 같은 트랜잭션에 Alice와 Bob의 개인키로의 Sign만이 유효해진다.

또한 mint property는 token acc가 어떤 토큰인지를 알려주는 property이다.

Program Derived Addresses

자 이제 진짜로 Token 전송해보자.
Token을 전송하기 위해서 다음과 같은 과정을 거칠 예정이다.

1. 먼저 Alice temp token acc X를 만들고,
2. 이 temp acc의 소유자를 Escrow Program으로 바꾼다.
3. 그럼 이제 Escrow Program이 이 temp acc를 Bob에게 돌려주는
   뭐 이런 느낌?

이를 위해 instruction.rs를 다시 봐보자

pub enum EscrowInstruction {

    /// Starts the trade by creating and populating an escrow account and transferring ownership of the given temp token account to the PDA
    ///
    ///
    /// Accounts expected:
    ///
    /// 0. `[signer]` The account of the person initializing the escrow
    /// 1. `[writable]` Temporary token account that should be created prior to this instruction and owned by the initializer
    /// 2. `[]` The initializer's token account for the token they will receive should the trade go through
    /// 3. `[writable]` The escrow account, it will hold all necessary info about the trade.
    /// 4. `[]` The rent sysvar
    /// 5. `[]` The token program
    InitEscrow {
        /// The amount party A expects to receive of token Y
        amount: u64
    }
}

위의 EscrowInstruction은 다음과 6개의 account를 받는다.

• Account 0은 어찌보면 당연하게도 컨트랙트를 서명할 signer account이다.
• Account 1은 위에서 말한 temp acc
• Account 2는 Alice token Y acc
  대괄호 안이 비어있다. 왜냐면 지금 이 transaction에서 write이 가해지진 않을거라
• Account 3은 escrow account
  얘는 교환 정보가 적히는 등의 수정이 가해지니까 writable
• Account 4는 Rent sysvar 인데 나중에 설명함
• Account 5는 Token Program인데 왜 필요한지 나중에 설명함

중간 정리

일단 용어를 정리하고 나니, 어느 정도 감이 잡히기 시작했다.
solana web3도 이제는 공부할 준비가 된 것 같고,
rust만 조금 더 이해한다면 코드를 보고 program 부르는건 할 수 있을 듯

다만 해결해야하는 문제가 몇 가지 있는데,

1. 일단 튜토리얼에선 공개키,비밀키 조합의 account를 직접 이용했기 때문에, 실제 서비스의 방식과는 차이가 있다.기존의 MetaMask처럼 트랜잭션을 만들고, sign을 요청하는 방식을 phantom으로 구현해봐야 할 것 같다. Phantom에도 이 내용이 나와있는데, 저번에 했을 때는 뭔가 잘 안되던데 아마도 cluster와 같은 개념에도 익숙해져야 되지 않나 싶음..
2. ethereum에서 ether와 마찬가지로, sol도 maximum_token_amount가 U64_MAX라서 javascript의 최대값을 넘어버린다. 그래서 배열의 형태로 잘라서 넘겨주는데, 이 부분이 상당히 귀찮아보임.. 뭔가 ethers.utils처럼 라이브러리를 만들면 좋지 않을까 싶다.

최종 정리

http://www.dalgonamint.com
홈페이지 완성...

부족하거나 힘들었던 것

Program Side

• Account에 관련된 개념을 처음에 잡는 것이 쉽지 않았다.. 아무래도 솔라나에 한정된 개념이기도 하고, 이더리움이랑은 많이 달라서 익숙하지 않았다. 또한 Account가 Program으로부터 만들어진 account인지, signer인지 등등 종류도 많고, 사실상 account가 state의 역할을 하기 때문에 굉장히 많은 account를 만들어낸다는 점이 처음에는 어려웠다.
  다만, 살짝 익숙해진 지금에는 이더리움의 mapping보다는 솔라나의 많은 account를 만드는 방식이 조금 더 안전한 방법이라는 생각이 든다. 이더리움에서는 mapping과 contract balance에 차이가 생길 수 있는데, 솔라나는 각각의 account로 상태를 관리하기에 그럴 일이 없으니

• SPL token과 같은 기본적인 라이브러리에 대한 문서가 없다. 주석으로 짤막하게 적혀있긴 하지만, 기본적으로는 코드를 찾아봐야 한다는 것이 뉴비 개발자 입장에서는 어려운 일이었다. 그래도 하다보니 익숙해지긴 했음

• 프로그램 디버깅을 Rust testing으로 했어야하는데, TS으로 그걸 돌리려다보니까 쉽지 않았다.

• rust 개념 부족 (현재 공부중..)

Frontend Side

• Typescript에 대한 개념 부족... (얼른 공부해야겠다)
• 환경 설정하는 것이 어려웠다. 처음 해보는 방법이기도 했고, process.env 라는 키워드도 처음 본거라 쉽지가 않았다
• Solana Web3 또한 라이브러리 docs가 정말 거의 없는 수준이었다. 중요한 부분들도 놓치기가 정말 쉬웠고, 또한 SPL Token JavaScript API 같은 경우는 아예 Document가 없었다. 그래서 그냥 코드를 읽어서 쓰는 수 밖에 없었던 것이 슬펐다. 앞으로 수월한 개발을 위해서는 핵심 메서드 정도는 미리 암기해두는 것이 좋을 것 같다.
• 에러 처리를 처음 해봤는데, 에러 메시지마다 에러를 다르게 처리하는 부분을 제대로 구현해보지 못했다. 시간이 더 있었다면 이 부분까지 처리를 해보고 싶었는데 아쉬운 부분이었다.
• Solana에도 web3-react와 같은 라이브러리가 있었는데, 이를 늦게 발견해서 적용을 해보지 못한 부분도 아쉬웠음. 다음 프로젝트에 적용 시켜볼 예정 https://github.com/solana-labs/wallet-adapter