• 백엔드에서 배지를 줄 건지, 프론트엔드에서 배지를 줄 건지 고민해 봐야겠지만 배지 자체는 nft 와 잘 맞는 아이디어
• 아직까지의 거래내용으로 봐서, p2p 리소스카 커 보이지는 않음
• mvp 가 있으면 좋을 것 같아요. 2-3일 내에 1차를 정하고 열심히 2주동안 개발해서 쉼표를 찍고 다음 페이지 하고 하는 걸 하세요. 그래야 질문이 나옵니다. 되도록이면 2주 뒤에 페이즈 1이 끝나길 바랍니다.

'MVP'(최소기능제품)

사전질문

• p2p 와 nft 를 함께 적용하게 되면 난이도가 어떠한지 궁금합니다

  → 1-2일이면 됩니다

  → nft는 하나뿐인 토큰인데..

  • erc - 721 처럼 하나뿐인 토큰을 여러개 만들 수도 있고
  • erc - 1155라고 해서, 여러 개를 만들 수 있는 토큰도 존재합니다 → 대신 갯수가 제한되어 있는듯?

• 스마트 컨트랙트를 이용하여 송금 시 서버(백)에 완료 되었다는 메시지를 보내는 것도 자동화 처리가 되는지 궁금합니다.

  • 블록체인에서 보여주는 게 쉽지 않다. 후순위로 넘겨라. 블록체인은 푸쉬서버에 알람을 보내야 하는데… 웹에서 푸쉬하는 건 의미가 없고 … 모바일의 경우에는 백엔드가 블록체인을 리스닝하다가 보냈다는 사실이 리스닝되면 푸시 알람을 보냅니다. 왜냐하면 푸시 알람 자체가 블록체인의 서비스가 아니기 때문입니다.
    • 구현 난이도 조금 있음,

• 후원자를 투명하게 공개하고 싶은데, 후원자 식별을 어떤 식으로 해야 하는 지 궁금합니다. 기본적으로 블록체인 전송은 주소를 가지고 전송하게 되는데, 후원자 정보에 주소를 함께 가지고 있어도 되는지 궁금합니다

  • 배지의 보유자를 보여주는 것만으로도 리스트를 알 수 있잖아요. 예를 들면 이 사람이 얼마 했는지 적지 않고 1억원 이상, 5000만원 이상으로 적잖아요. 그렇다면 5000만원 이상 기부한 사람을 보여줄 수는 있어요.
  • 블록체인의 데이터는 있기 때문에 어떻게든 보여줄 수 있어요.
  • 플래티엄 배지를 갖고 있는 사람의 리스트를 뿌려 주는 건 심플하게 해결 가능하단 겁니다
  • 주소는.. 주소 = 유저입니다. 여러분들이 생각하는 유저가 어떤 형태인지 모르겠는데 이름이냐 닉네임이냐 이런 것에 따라 다를 수 있잖아요. 여러분들이 생각하는 유저라는 개념에 대해 먼저 정의를 하시고 .. 별명을 설정하고 싶다면 주소와 별명을 매칭할 수 있는 컨트랙트를 만드는 것도 방법이고, db로 저장하는 것도 방법인데 필요에 따라 선택하시면 될 것 같습니다.

추가 질문

1. 블록에서 원하는 데이터만 조회가 가능한지? (속도 우려)

   • 가수에게 후원을 하면 일정 금액(가수별) 이상 후원 시 혜택을 주려고 하는데 DB에 리워드 포인트를 따로 저장할지 블록에 저장할지 잘 모르겠습니다. 블록에 저장할 시 블록이 너무 많아져 수수료 우려가 생기고 블록들 조회 시에 시간이 오래 걸릴 것 같고 DB에 저장할 시에 조작 우려가 고민이 되는데 어느 방향이 맞을지 고민이 됩니다.
   • 퍼블릭 네트워크에서 블록 동기화가 너무 오래 걸렸던 경험이 있다. 처음에 한 번 동기화를 하고 새로운 블록이 추가되면 노드들은 모든 블록을 다시 동기화 하는건지 아니면 새로운 블록만 받아오면 되는지?

   스마트 컨트랙트를 한번 짜 보면 답이 나와요. 여러분이 원하는 기능을 제공할 수 있는 function 을 만들면 됩니다. 리턴값으로 보내 주면 됩니다. 한번 해 보세요 바로 알거에요

   → 속도적인 측면에서는 답해주지 않았지만, 문제 없는 듯.

   → 원하는 데이터만 조회가 가능한듯

2. 안드로이드 플랫폼에서 private key를 저장하는 방법

   • samsung blockchain keystore library를 찾았는데 이거 이용하면 되는가?

     그냥 안드로이드에서 제공하는 키스토어를 쓰세요. 써보지 않아서 잘 모르겠는게 굳이 삼성꺼 써야 하나요? 그리고 삼성에서 하는거 제공하면 구글 앱스토어에서 오픈이 안 됩니다.

   • 다른 플랫폼(웹)에서 개인 키를 저장하는 방법은?

3. 블록체인 네트워크에 어떤 데이터를 저장해야 좋을까요? 블록에는 문자열 말고 다른 타입으로도 저장되는지?

   • 저희 서비스에서 필요한 데이터

     • 보낸 주소
     • 받는 주소
     • 후원 금액
     • 후원 메세지

     이미지같은 대용량은 안되고… json도 문자열이니까 뭐 가능은 합니다. 바이너리도 가능해요. 용량만 작다면

4. 블록체인의 정보를 db에서도 보유하고 있어야 하는지?

   • 일정 주기마다 db와 블록들이 일치하는지 검증해야하는지(아마 오래걸릴 것 같음), 아니면 db보유 없이 블록체인 정보만으로 처리해야 하는지

   일단은, 블록체인은 write 가 느리지 read 가 느리진 않습니다.

   백엔드 서버가 주기적으로 블록체인으로 정보를 요청해서 받어ㅏ온다..? 구현하는 게 쉽지 않을 걸요? 블록체인의 정보를db로 쌓는사람들은 이더스캔 서비스를 하는 사람들이에요. 엄청 많은 데이터를 레인지 쿼리를 써서 보여줘야 하는 케이스가 아니고서는 굳이 그럴 필요는 없죠.

   컨트랙트를 어떻게 구성하느냐에 따라서 read 속도가 떨어지지 않게 구성할 수 있어요.

   하지만 모두 다 가지고 와서 루프를 돌려서 머 어쩌고 하면 느리겠죠?

   하지만 자료구조를 잘 짜면 심플하게 해결 되겠죠

   스마트 컨트랙트는 가장 원시적인 형태의 read write 형식이라고 할 수 있습니다.

   자료구조를 잘 짜시라는 겁니다. 원시적인 것들에 많이 좌우된다는 거에요.

   이더 쌓는거 이더리움같은거는 20초정도 되잖아요. write 속도는 어쩔 수 없습니다.

   하지만 read 속도를 이더스캔하는 것은 쉽지 않을 것이에요.

   현실적 + 어려움을 해결했을때의 이점이 있는지를 생각해 보세요.

   진짜 필요하다 싶으면 머 2,3초 기다리라 하세요. 그리고 나중에 추가 구현 하세요

   지금 이걸 고민하면 시간이 더 흐를 거 아니에용 ㅎㅎ

   하다 보시면 이게 문제가 아니라는 것을 깨달을 것입니다.

5. FE에서 지갑을 만드는 것과 BE에서 지갑을 만드는 것이 장단점이 있다는데 뭐가 다른지?

   • FE, BE, 이더리움 네트워크 간의 통신 방식? 효율성?

   백엔드에서 지갑을 만드는 케이스 → 원칙적으로 맞지 않음. 왜냐하면 백엔드가 그사람인 척 할수 있기 때문..

   공인인증서의 프라이빗키를 절대 은행이 보유할 수 없어요.

   백엔드에서 지갑을 만드는 거는 어드민 키를 갖고 있는 것과 같은 뜻인데, 이는 탈중앙화에 완벽하게 위배됩니다.

   그런데 지갑이란 건 사용성이 아주 불편하죠. 개인키를 잃어버리면 복원이 안 되죠…

   그래서 여러 장치를 심어 놓는데…

   web2에서도 private 키를 서버에 저장하는 것은 블록체인에서만!! 보입니다. 극도의 사용성을 위해 보안성을 희생하는 거죠… 어쨌든 올바른 방향은 아니라는 거

   원칙은 클라가 프라이빗 키를 보관하는 것이 맞다는 것을 기억하세요.

6. 롭슨넷에 참여하기 위해 블록 동기화를 진행한 적이 있습니다. 그런데 동기화 시간이 너무 오래 걸렸습니다. 거기서 새로운 블록이 계속 추가되면 각 노드들은 모든 걸 다 동기화 해야 하는지, 아니면 새로 생긴 것만 받아오면 되는지 궁금합니다

   → p2p라 토렌트랑 비슷해요. 이게 열심히 받고 있으면 다른 사람들이 또 받기 때문에 시간이 등비수열로 증가합니다.. 어쩔 수 가 없어요. 그냥 2박3일 걸리는걸 당연하게 생각하시면 됩니다.

   결론은 처음부터 쌓지 않아요. 그럼 영원히 못 받죠

   토렌트랑 비슷하다고 생각하세요~