Dreaming Deve1oper

Unity Editor에선 카메라 시점이 자유로웠지만, WebGL로 빌드 이후엔 좌우로 카메라 시점을 변경하는것이 불가능했다. => WebGL 카메라는 일반적으로 -Z축 아래를 가리키므로 카메라가 향하는 방향으로 이동하려면 Z축을 카메라 위치에 곱해야한다고 한다. #참고 코드 -> 파이선 코드이기 때문에 필요한 부분만 잘 빼서 사용하자 const m4 = twgl.m4; const v3 = twgl.v3; const gl = document.querySelector("canvas").getContext("webgl"); const vs = ` uniform mat4 u_worldViewProjection; uniform mat4 u_worldInverseTranspose; attribute vec4 po..

1. 메타마스크 회원정보 저장 (로그인정보는 어디에 저장되는지?) -> 우리가 알기로는 이더리움 네트워크의 분산 노드에 저장됨. -> 니모닉코드를 풀면 나옴 메타마스크는 니모닉키를 보관하지 않음. 계정과 연결된 이메일 주소 없음 니모닉 코드는 한번만 주어지며 변경/재설정이 불가능 백엔드에서 지갑에 로그인할 수 없음 니모닉키는 로컬에서 계정, 주소당 하나씩 개인키를 만드는데 사용된다 -> 이 계정은 블록체인 네트워크에 저장되며 계정의 잠금을 해제하는데 사용된다. 로컬상에서 메타마스크를 삭제하면 데이터가 전부 삭제되지만 해당 로컬에서 수행한 모든 트랜잭션은 블록체인에 저장되어있다. 로컬과 이더리움 네트워크 상 어딘가에 저장된다. https://www.youtube.com/watch?v=0PeoP_C5Axg ..

과제의 목적 및 필요성 본 프로젝트는 기존 기부 시스템의 문제점 및 취약점을 인식하고 이를 개선하는 것에 목적을 두고 있다. 기존 기부 프로세스의 경우, 중앙화를 거친 현금의 직접적인 이동 과정에서 여러가지 문제점이 발생하고 있다. 해당 프로젝트를 통해 블록체인이라는 탈중앙화 방식을 도입하여 이와같은 문제를 해결하는데 중점을 두고자 한다. 과제 수행방법 및 결과물 개발계획 이더리움 기반의 탈중앙화 환경에서 모든 기부금이 운용되며, 기부의 전 과정은 네트워크의 분산노드 상에 블록(Block)상태로 저장되고, 이는 누구나 조회가능하다. 기존 P2E(Play to Earn) 모델을 차용하여 구축된 블록체인 기반 유니티 환경에서 다양한 플랫폼을 통하여 기부에 대한 진입장벽을 낮춘다. Solidity를 통해 작성..

Wallet To Wallet 전송 방식이 맞는가? -> 시스템 내 모든 토큰 전송 방식은 wallet to wallet이 아님 -> 전송계약을 통해 스태이킹 후 조건 일치 시 전송 이더리움 네트워크를 사용하는 이유? -> 기부과정의 투명성 -> 기부과정 조회 가능 -> 분산된 기부블록등리 서로의 데이터 공유 시연할 때 사용할 user divce (노드의 수) -> PC 2대: User device -> PC 1대: Monitoring device -> PC 1대: Donation device 메타마스크를 사용하는 이유? -> 타 지갑에 비해 낮은 진입장벽 -> 크롬브라우저를 통한 가벼운 접근성 -> 높은 인지도 유동성 토큰/유동성 풀을 사용하는 이유? -> 토큰의 보안성 -> 토큰 발행 후 유동성 풀 ..

web3 API 목록을 보면 기능이 전부 존재하는데 굳이 니더리움을 사용해야하는 이유?? -> 니더리움은 C#에서 Geth나 parity같은 이더리움 네트워크에서 제공하는 JSON RPC를 C#에서 사용 가능하도록 해주는 라이브러리이며 js로 제공되는 web3 라이브러리의 C# 버전이다. -> 그렇다면 유니티(C# 사용)에서 이더리움의 기능을 사용하기 위해선 니더리움 sdk가 필요한것이다 라고 이해했다. https://web3js-kr.readthedocs.io/ko/latest/ └ Web3.js https://docs.nethereum.com/en/latest/ └ 니더리움 백서 https://medium.com/gocryptobot/unity%EC%97%90%EC%84%9C-nethereum%EC%..

이더리움 -> 가스비가 비싸고 느리다는 문제점이 존재. -> 많은 정보 존재. 이더리움의 가스비 비용 문제를 해결 가능한 네트워크 -> 클레이튼 -> 폴리곤, 루나텔라 클레이튼 가스비가 저렴하다 (몇백원대) 현실적으로 메인네트워크에 상장 할 수 있다 이더리움의 소스코드를 기반으로 개발 이더리움과 높은 호환성 (계정, 트랜잭션, 서명 알고리즘, etc...) 교수님이 return 할 가능성 ↑ (이더리움에 대해 까였다고 클레이튼을 가져온것이냐고 물을 수 있으며 현직자들은 클레이튼에 대한 시선이 크게 좋지 않다. 이더리움을 그냥 가져다 쓴것뿐이라는 인식이 있기 때문) https://github.com/klaytn/caver-java └ 클레이튼 Dapp API 클레이튼 합의 노드 Consensus Node ..

현행 p2e 시스템에서 토크노믹스 부분을 제외하고, unity에서 web3gl(web3에 연결가능)로 빌드 후, 메타마스크에 연결하여 로그인 -> 사용할 이더리움 메인넷상에 배포한 스마트계약 및 토큰이 사용되며 이 토큰은 유니티에서 진행되는 간단한 게임이 끝난후 계약조건이 일치하면 유저의 로그인지갑에 전송, 이후 유저가 토큰을 기부처로 기부하는 방식 이 과정을 교수님께 설명하니 네트워크 구조적으로 질문이 많이 들어옴. 1. 시스템 진행에 따른 플로우 차트가 정확히 어떻게 되는지? (node to node 형식으로) [로그인] 유저디바이스 -> 메타마스크(로그인) -> 노드추가(이더리움 메인넷, 사용자정보가 추가된 노드에 블록으로 저장) [시스템에 토큰요청] 유저디바이스(토큰전송요청) -> 이더리움 클라이..

-

-> 해당과정에서 데이터가 블록 형식으로 저장되어 네트워크의 모든 참여자에게 전달된다고 적혀있다. 그렇다면, 이 참여자라는것은 시스템을 사용하는 유저(디바이스)라는 것인가? 그리고 그것을 노드라고 이해하면 되는가? 참여자 = 채굴자 = 노드. 노드가 늘어난다 = 참여자가 증가한다 = 채굴자가 늘어난다. -> 스마트 컨트랙트상에서 트랜잭션이 이루어질때 그 과정에서 거치는 노드가 많을수록 보안성이 높아진다 트랜잭션은 블록에 기록되는 데이터 중 하나이다. 즉, 스마트컨트랙트와 노드는 관련이 없다. 하지만 많은 노드들이 검증을 하면 좋긴하다. -> 체리 기부 플랫폼의 노드 구성인데 노드가 6개라는것이 이해가 가지 않는다. 해당 서비스를 이용하는 사용자(디바이스)가 전부 노드라면 노드는 계속해서 증가해야하는것이 ..

피드백) Q1. 시스템 동작에 필요한 디바이스의 갯수 (실제 시연 시) -> 유저 디바이스 / 트랜잭션 흐름 보는 디바이스 / 기부처 디바이스 Q2. 이더리움 네트워크 안에 필요한 노드의 갯수 -> 좀 더 확립이 필요. Q3. 트랜잭션 검증은 누가 하는 것인지? (검증하는 주체) > 트랜잭션을 받아 검증하는 주체가 확실히 누구냐? -> 이더 네트워크에 배포한 스마트계약(EVM)에서 검증. Q4. 왜 굳이 이더리움을 사용해야하는가? (근본적인 이유와 기존 네트워크와의 차이점 서술) -> 스마트계약을 통한 신뢰성보장이 차별점 및 이점때문 Q5. 서버를 사용하지않는다면 프론트단에서 넘어온 데이터 및 여러가지 정보들은 구체적으로 어디에 저장이되는가? (단순히 이더리움 네트워크상에서가 아닌) Q6. 기존에 존재하..