Infura (=Cloudflare

1. 수신주소 / eth 갯수를  발신자 private key로 sign하여 robston 네트워크의~ (infura) ?  로 보낸다. (json api call. ?)

2. 이후 ropston network에서 전송받은 데이터(블록체인화된) 을 검증(validate) 하고

3. 이후에 우리는 위를 통해 transaction의 hash를 받음으로서, 이 계약의 최종적인 검증을 할수있다.(확인가능하다)

 

코드분석

--> TransferEther() 함수에서 

Url = InputUrl.text; ~~ 

PrivateKey = ~~

AddressTo = ~~

Amount = ~~ 

--> 위와 같이 (프로젝트의 UI에 입력하는창과 매칭되는부분) 이를 이용해서 위의 정보를 입력받는다. 

 

 

---

인퓨라 

다른 블록체인과 같이 이더리움도 확장성 문제(Scaling Issue)를 가지고 있습니다. 대부분 확장성 문제는 Transaction per second, 즉 얼마나 많이 전송할 수 있는지를 이야기합니다. 이 문제는 플라즈마, 크로스 체인, 샤딩등 많은 방향으로 개발되고 있습니다. 하지만 또 다른 확장성 문제가 있습니다. 이것이 인퓨라(Infura)에서 해결하려고 하는 확장성 문제인데요. 바로 "read"입니다. 

보통의 웹 인터페이스 앱에서 데이터 베이스를 사용할 때 읽는 기능을 사용합니다. 예를 들어, 네이버를 핸드폰으로 키시면 보이는 모든 데이터들은 데이터베이스에서 불러온 "read"들입니다. 그러다가 맘에 드는 레이더 릴레이 블로그에 '좋아요'를 누르시면 "write"를 사용하신 겁니다. 이와 같이 데이터베이스의 대부분은 '쓰기'보단 '읽기'를 훨씬 더 많이 사용합니다. 이더리움 블록체인에서도 마찬가지입니다. 인퓨라에 따르면 2월 기준 2천만 번이 넘는 '읽기'가 요구되었습니다. 

엄청나게 많은 숫자가 요구되기 때문에 개인의 노드를 구축해서는 과부하가 걸리기 쉽습니다. 따라서 이더리움 네트워크에서 dApp을 개발하려는 장벽을 낮추기 위해 인퓨라팀은 노드를 제공하고 인프라를 제공합니다. Cloudflare 같은 서비스를 제공한다고 이해하면 쉽습니다. 복잡한 인프라를 개발팀이 직접 돌릴 필요가 없습니다.

 

async
ABI	to call smartcontract (json-rpc)
txns	= transcation