BlockChain

1. 비트코인 vs 이더리움

• 비트코인 2009년 사토시 나카모토로 알려진 익명의 개인 혹은 그룹에 의해 출시된 최초(x)의 암호화폐.
• 가장 널리 사용되면 최근엔 ETF에 승인되어 여러 기관들이 보유중.

합의 알고리즘

비트코인

• 비트코인은 Proof Of Work(POW), 작업 증명방식을 사용. 채굴자가 네트워크에서 새로운 블록을 생성하기 위해 수학적 문제를 해결하는 과정을 통해 채굴이 이루어짐. 이 과정을 통해 신뢰할 수 있는 블록체인이 유지

이더리움

• 초기에 POW를 사용했지만, 그래픽 카드 채굴, 발열로 인한 환경문제 발생, 2021년 POS 방식인 비콘체인 출시를 했고, POW 와 POS 를 모두 운영하다 2022년 9월 15일 두 체인이 하나로 통합 되는 더머지 이후에 POS 로 운영 32개의 이더리움을 묶어 예치하면 이를 바탕으로 지분을 증명하는 방식.

[Ethereum] 이더리움 1.0(Eth1), 이더리움 2.0(Eth2) 용어 폐지

블록체인 기능

비트코인

• 비트코인은 개인간 전자화폐시스템으로 주요한 목적은 안전하고 투명한 거래. (분산원장)

이더리움

• 이더리움은 블록체인 위에 스마트 계약이라고 불리는 프로그램을 실행시키는 일종의 플랫폼. 이더리움은 그 플랫폼에서 사용되는 네이티브 코인, 이 플랫폼에서 개발자들은 DAPP 들을 개발할 수 있음.

내부적인 로직

비트코인

• 비트코인은 트랜잭션의 처리와 관련한 단순한 스크립트 언어를 사용. 이는 기본적인 트랜잭션 유형에 대한 몇 가지 제한적인 스크립트를 실행할 수 있는 기능을 제공.

→ 최근에는 스택스, 루트스탁, 오디널스, runes 등 다양한 방식으로 비트코인 위에서 컨트랙트 및 비문 등의 여러 도전을 하고 있고, 비트코인 layer2, layer3 도 연구가 많이 되고 있음.

이더리움

• 이더리움은 트랜잭션을 처리하기 위해 튜링완전한 스마트 계약 언어를 사용. 이더리움 스마트 계약은 거의 모든 계산을 수행할 수 있고, 더 복잡한 조건과 로직을 적용할 수 있음.

2. Smart Contract ?

스마트 컨트랙트 : 스마트 컨트랙트는 계약이나 계약에 필요한 작업을 자동하나는 자체 실행 프로그램. 완료되면 거래를 추적할 수 있고, 되돌릴 수 없다.

스마트 컨트랙트의 특징

• 스마트 컨트랙트는 코드로 작성 되어 있고, 지정된 조건이 충족되면 자동으로 실행. 중앙기관, 법률 시스템 또는 외부 집행 메커니즘 없이 다른 익명의 당사자 간에 신뢰할 수 있는 거래 및 합의가 수행
• 신뢰성 : 블록체인 위에 배포된 스마트 계약은 변경이 불가능한 코드로 작성, 따라서 계약을 신뢰가능. → 블록체인의 연속성(시퀀스) 때문, 블록과 체인의 사슬 구조로 블록 이전 값의 해시값을 포함하고
• 일련의 과정이 진행되 과정 : 단순한 컴퓨팅 연산 opcode 어셈블러랑 설명 하면 좋을듯.

스마트 컨트랙트 역사

• 비트코인이 나오기 10년전에 1998년 ‘비트 골드’ 라는 가상화폐를 발명한 미국의 닉자보(닉사보)에 의해 제안됨.
• 스마트 컨트랙트의 계약조건을 실행하는 컴퓨터화된 거래 프로토콜로 정의

3. 합의 알고리즘

합의 알고리즘은 분산 네트워크 상에서 서로 신뢰관계가 없는 노드들이 특정하게 정의된 절차를 통해 수학적으로 계산된 결과값을 상호 검증함으로써 시스템의 무결성을 보장하는 알고리즘.

→ 블록체인 네트워크에서 새로운 블록이 생성되고 추가되는 과정을 관리하고 결정하는 방법을 정의. 즉, mining 방식을 정의한다 라고 생각하면 쉬움.

롱기스트 체인의 시빌어택을 보완하기 위한 것이 proof of work 다.

Proof of Work(POW : 작업 증명)

비트코인의 합의 알고리즘으로 가장 잘 알려진 합의 방식

채굴자들은 네트워크에서 새로운 블록을 찾기 위해 수학적 문제를 해결 해야함. 이를 통해 새로운 블록을 추가하고 보상을 받음.(마이닝과 인센티브)

Proof Of Stake(POS : 지분 증명)

POS는 채굴자가 자신이 소유한 암호화폐를 걸고 새로운 블록을 생성할 권한을 얻는 방식. 보증된 채굴자는 자신이 소유한 암호화폐를 스테이킹하고, 네트워크에서 새로운 블록을 찾을 때 확률론적 선택. (스테이킹) Istanbul Byzantine Fault Tolerance(IBFT : 이스탄불 비잔틴 장군 허용)

이스탄불 비잔틴 허용은 이기종(다른 유형의) 노드 간에 신뢰할 수 있는 합의를 달성하는데 중점을 둠.

노드들 간의 통신이 불안정하거나 악의적인 행동을 하는 노드가 존재할 때, 전체 시스템이 여전히 일관된 상태를 유지할 수 있는지에 대한 문제. IBFT는 이런 상황에서도 합의를 도출하고 블록체인의 일관성을 유지하는데 사용.

POH : (Proof Of History : 역사 증명)

솔라나에서 사용되는 합의 메커니즘. 솔라나의 높은 처리량과 낮은 거래비용을 제공하는 핵심 기술.

POH는 블록체인에서 시간을 정의하고 기록하는 방식으로 동작. POA : (Proof Of Authority : 권위 증명)

POA는 프라이빗 or 퍼미션 블록체인에서 사용. POA에서는 네트워크 참가자들 중에 일부가 신뢰할 수 있는 ‘권한’이 있는 노드로 지정되며, 이러한 노드들이 블록을 검증하고 새로운 블록을 생성하는 권한을 갖음.

→ 노드들이 신뢰할 수 있는 기관 혹은 회사로 이루어져 합의시간이 짧고 안정성과 신뢰성이 높음.

→ 하지만, 프라이빗 블록체인을 기반으로 하기 때문에 비교적 중앙화 되었다고 볼 수 있음.

4. Gas & Fee

• Gas : Gas는 이더리움 네트워크에서 실행되는 연산(ex: 계산, 저장, 메모리 액세스 등)이 소비하는 비용. 이더리움 가상머신(Ethereum Virtual Machine, EVM) 에서 각 연산에는 고유한 비용(opcode)이 할당되어 있으며, 이를 통해 네트워크 리소스가 효율적으로 사용. 높은 연산 복잡도를 가진 스마트 계약 또는 트랜잭션은 더 많은 가스를 소비하게 됨.
• 가스는 이더리움 네트워크의 트랜잭션 처리 과정에 사용되며, 각 트랜잭션은 소모된 가스의 양에 따라 수수료 지불. 단위는 Gwei
• Fee : Fee는 사용자가 이더리움 네트워크에서 트랜잭션을 실행할 때 지불해야 하는 비용을 의미. 이더리움 트랜잭션은 가스비를 결정하게 되고, 가스비는 가스 가격과 소비된 가스양을 곱한 값.

가스비 = 가스 한도(Gas used) x 가스 가격(Gas Price)

• OPCODE : 가스는 트랜잭션이나 스마트 컨트랙트를 실행하는 데 필요한 작업량을 측정, 해당 작업량에 따라 지불해야 할 수수료를 결정하는 단위. 이때 OPCODE는 EVM 명령어에 할당되는 연산 비용에 의해 결정. (어셈블러와 비슷..)

5. 블록체인 트릴레마

블록체인 트릴레마 : 블록체인이 가지는 3가지 딜레마를 표현, 비탈릭 부테린이 제시

확장성

• 모듈러
• 모듈러 블록체인 개요 - HackMD
• 모놀리틱 블록체인
  • 기존에는 모놀로틱 블록체인(한개의 계층에서 실행과 합의 모두 수행)
  • 간단하게 이해하면 기존에 웹은 js html css 로 작업했지만, react를 사용하면 컴포넌트 단위로 쪼개서 탈부착 하는 형태로 사용. 이와 비슷하게 모듈 형태로 각각의 독립적인 작업을 수행한다고 생각.
• 블록체인 레이어 개념 :

블록체인 레이어 용어 정리

• Layer2 :
  • 기존 이더리움의 경우 속도 및 확장성의 문제가 있었음. 이를 해결하기 위해 이더리움의 레이어가 아닌 다른 레이어를 올려 이를 해결하기 위함.
  • layer2는 이더리움 온체인이 아닌 오프체인에서 검증을 진행하고 이더리움의 레이어로 말아 올리는 일종의 롤업
  • 대표적으로 옵티미스틱(op) 와 영지식(zk) 가 있음.
  • 옵티미스틱의 경우 사기증명과 영지식의 영지식 증명으로 증명을 함.

탈중앙화 (Decentralization)

• 블록체인은 분산된 네트워크로 구성되어 있음. 중아 집중화된 제어 없이 많은 참여자가 네트워크를 운영하고 보안을 유지할 수 있음.

보안성(Security)

• 블록체인 시스템은 악의적인 공격에 보안을 유지해야함. 이는 합의 알고리즘에 의해 보장되고, 블록체인의 안정성과 신뢰성을 보장.

6. 블록체인 블록의 구조

트랜잭션이란?

• 블록체인 트랜잭션은 블록체인 네트워크에서 수행되는 작업 또는 거래를 나타냄. 디지털 화폐를 전송하거나 스마트컨트랙트를 실행하는 등의 활동을 포함. 블록체인에서 트랜잭션은 네트워크의 분산된 노드들에 의해 검증되고 기록되며, 블록체인의 특정 블록에 포함됨

7. 코인 vs 토큰

코인

• 독립적인 블록체인 네트워크에서 발행되는 암호화폐
• 자체적인 블록체인을 보유하며, 해당 블록체인에서 네이티브 통화로 사용

토큰

• 토큰은 다른 블록체인 위에 구축되어 발행된 자산
• 아래서 나올 ERC20 과 ERC721 같은 표준들을 사용하여 스마트 계약을 통해 발생, 주로 프로젝트의 토큰 세일이나 플랫폼에서 사용
• 메인넷(자체 블록체인의 유무라고 이해하면 쉬움)

8. Erc20 vs Erc721

EIP : 이더리움 개선 제안, 오픈소스로 이더리움 개선사항을 올리고 이를 여러 작업을 통해 실제 이더리움 네트워크에 반영 대표적으로 최근에 진행한 eip 4844 가 있음.

• Erc20 (Ethereum Request for Comment 20): 이더리움 네트워크의 개선안을 제안하는 EIPs 에서 관리하는 공식 프로토콜, 이더리움의 토큰 표준 스펙, 이더리움과 호환성이 있는 모든 요구 사항을 충족시키는 표준은 ERC-20으로 간주됨.
• Erc721 (Ethereum Request for Comment 20) : 이더리움 스마트 컨트랙트를 기반으로 하여 고유한 식별자를 가진 토큰, ‘NFT(Non-Fungible Token) : 대체 불가능한 토큰’. ERC-721 표준은 토큰을 생성, 소유, 전송 및 거래할 수 있는 방법을 정의.

9. 노드, JSON-RPC, Third-party provider (Infura, Alchemy)

Node

노드는 블록체인 네트워크의 구성원으로 검증, 블록생성, 네트워크 유지등의 역할.

Full Node 풀 노드

• 풀 노드는 블록체인 네트워크의 전체 복사본을 가지고 있고, 모든 블록과 트랜잭션을 저장하고 유지. 이들은 네트워크에서 블록을 검증하고 새로운 블록을 생성할 때 필요한 데이터를 제공함.

Lightweight Node 라이트 노드

• 라이트 노드는 전체 블록체인의 복사본을 유지하지 않고, 블록 해시와 트랜잭션에 대한 일부 정보만을 저장. 주로 블록체인에 대한 정보를 쿼리하거나 트랜잭션 검증 시 사용.

JSON-RPC

JSON-RPC(Javascript Object Notation-Remote Procedure Call) : 원격 프로시저 호출을 위한 프로토콜 중 하나. 클라이언트가 서버에게 json 형식의 데이터를 사용하여 원격으로 프로시저를 호출할 수 있게 해줌.

1. http 혹은 다른 프로토콜을 통해 json 형식으로 통신. 가벼운 프로토콜로 간편하게 이용가능.
2. 플랫폼 독립적으로 여러 프로그래밍언어와 플랫폼에서 사용가능.
3. 원격호출 : 클라이언트는 서버에게 원격으로 프로시저를 호출 가능. 클라이언트는 서버의 함수나 메서드를 실행하고 결과를 받아올 수 있음.

Third-party provider

1. Infura
   • Infura 는 노드 공급자이며 Infura 자체에서 관리하는 노드를 통해 이더리움 블록체인에 ‘플러그인’ 할 수 있게 도와줌. 이런 프로바이더를 이용해서 개발자는 비용과 시간 절약하고 작업량을 줄여줌.
2. Alchemy
   • 블록체인 개발자들이 탈중앙화 애플리케이션을 더 쉽게 구축하고 관리할 수 있도록 도와주는 플랫폼. 알케미는 블록체인 네트워크와 상호작용하고 스마트 계약을 배포하고 실행할 수 있는 도구와 서비스를 제공.

→ QA) 근데 블록체인은 제 삼자 없는 p2p 방식 아닌가요?

→ 블록체인의 노드 혹은 인프라를 사용하기 위해선 자원과 기술적 능력들이 많이 들기 때문에 좀 더 개발에 집중하기 위하여 서드파티 프로바이더를 사용함. ex) 예시로 web2 에서 구글 0auth, 혹은 카카오로그인 등을 사용하여 login 프로바이더를 사용하는 것으로 생각해도 좋을듯.

10. 웹 아키텍쳐 vs 블록체인 아키텍쳐

• 웹 아키텍쳐

• 블록체인 아키텍쳐10. 웹 아키텍쳐 vs 블록체인 아키텍쳐
  • 웹 아키텍쳐

  

  

  
  
  • 블록체인 아키텍쳐
    

    

11. 블록체인 산업 구조

• Develop
  • Dapp(NFT, TOKEN, DEFI, DEX, AI)
  • Core(Layer, Infra, bridge, multichain)
  • CEX(거래소, STO거래소, 증권 거래소)
  • 암호학자, 수학자, 경제학자
  Fellowship of Ethereum Magicians
• Minning
  • ASIC, 아이스리버, 기타 채굴 장비
  • GPU (3090)
  • 대규모 채굴 광부로 이루어진 컴퓨팅 파워 혹은 채굴 비즈니스를 하는 마이너들.
• research
  • Blockchain researcher
  • 블록체인 기자
  • community manager, business developer
  • discord moderator, telegram, youtube, blog
•  블록체인 산업 구조에 대표적인 세가지로 보여지는데, dApp 혹은 core를 개발하는 개발자 및 암호학, 경제학자들로 이루어져 있고, 컴퓨팅 자원 혹은 staking 을 대신 묶어주는 광부들과 research 와 마케터들로 이루어져 있고, 이 세가지가 모두 각자의 비즈니스를 하면서 생태계를 이루어 나감.

12. web1.0 → web2.0 → web3.0

Difference Between Web 1.0, Web 2.0, and Web 3.0 - GeeksforGeeks

증권의 역사

• 20세기 중순 ~ 21세기 초 : web1.0 시장 (증권 시장 )
• 2007년 ~ 현재 (스마트폰 보급 ) : web2.0시장 (증권 시장 부흥)
• 2009년(비트코인 등장) / 2016년~ 현재 : web3.0시장 (암호 화폐?)
• web4.0 은 멀까요?

ERC20 토큰을 개발하기 위해 쉘 명령어로 여러 작업들을 진행합니다. 

npx create-react-app erc20

npm i truffle

npx truffle init

1. npx create-react-app erc20 

cra 를 이용하여 erc20 개발을 위한 세팅을 진행합니다.

2. npx i truffle

로컬에서 테스트를 진행하기 위해 truffle을 다운받습니다.

3. npx truffle init 

truffle을 초기화합니다.

npx truffle init 을 진행하면 초기 세팅이 되는데 3개의 폴더가 생깁니다. 

3- 1. contracts 폴더 : 솔리디티 코드들을 작성한 sol 파일을 담아 놓을 폴더, 컴파일을 진행하면 build 라는 폴더가 생기고 컴파일된 파일들이 json 형태로 생성됩니다.

3-2. migrations 폴더 : 컨트랙트 배포를 진행할 js 코드 구문 작성

3-3. test 폴더 : 테스트 파일 작성 폴더.

4. truffle.config 

- 네트워크 속성과 솔리디티 컴파일 버전 정보 명시

5. 컴파일 

- contracts 폴더에 솔리디티 파일을 작성하고 

npx truffle compile

- .build 폴더가 생성되고 컴파일된 내용이 json 파일로 생성된다.

- 배포를 하거나 컴파일을 진행하면 json 파일의 내용이 변경된다. 

- 컴파일 -> 배포

npx truffle migrate

# remix로 배포하기

- 우리 로컬 디스크에 있는 파일의 내용을 요청으로 보내서 remix 환경에서 쉽게 배포를 진행할 수 있다. 

- 

npm i -g @remix-project/remixd
# 우리 디스크 폴더 경로의 파일들을 요청
remixd -s "터미널 상에서 어느 경로를 보낼지" --remix-ide "어디의 remix 페이지 경로에 보낼지"

remixd -s "./contracts" --remix-ide "https://remix.ethereum.org/"

remix -s . --remix-ide "https://remix.ethereum.org/"
# 페이지에서 요청을 받아주길 대기중인 상태

# remix 페이지에서 connect to localhost

위와 같은 설정을 한 후에 remix 에서 

상단의 실행환경을 metamask에 provider로 바꾸어주고 자신의 로컬 환경 ganache의 환경으로 바꾸어준다면 자신의 로컬 폴더 내에 있는 sol 파일들을 remix로 호출하여 배포를 편리하게 할 수 있다. 

ERC20 

- ERC20 Ethereum Request for Comments 약자 

- ERC20에서 20은 특정 제안의 번호를 매긴 것. 토큰의 생성이나 발행등의 규칙을 의미

- 코드의 내용이 작성되어있는 제안

- 숫자는 큰 의미 없고 제안의 식별의 숫자라고 보면 된다. 

SPA (Single Page Application)

Single Page Application의 약자로 단일 페이지로 구성된 웹 애플리케이션. SPA가 등장하기 전에 구성하던 방식인 서버 사이드 렌더링(SSR)의 경우, 화면에 보여질 리소스를 서버로 요청하고, 서버로 부터, 받아온 리소스를 렌더링한다.

SPA의 경우 렌더링의 역할을 서버에 넘기지 않고 브라우저에서 처리하는 방식이다. 모든 정적 리소스를 AWS S3같은 정적 저장소에서 다운로드하고, 이후 새로운 페이즈를 요청하면 요청시 갱신에 필요한 정보만 바꾸어 화면에 띄어주면 된다.

SPA의 장점

• 새로운 페이지 요청 시 전체를 렌더링하지 않고, 변경되는 부분만 갱신하기 때문에 전체적인 트래픽 감소와 렌더링에서 좋은 효율을 가진다.
• 새롭게 갱신 되는 부부만 렌더하기 때문에 새로고침이 발생하지 않고 빠른 이동이 가능
• 번거로운 요청과 응답 없이 정적 파일 내에서 변경된 부분만 렌더하기 때문에 불필요한 트래픽이 감소하고, 속도, 반응성 향상으로 자연스러운 UX 사용자 경험을 제공한다.
• 모듈화 또는 컴포넌트 개발이 용이.
• 백엔드와 프론트엔드가 명확하게 구분 가능

SPA 단점

• 처음 구동할 때 정적리소스를 모두 가져와야 하기 때문에 초기 구동속도가 느리다.
• SPA 구조 상 데이터 처리를 클라이언트에서 하는 경우가 많은데 JS 코드가 외부에 노출 될 위험이 있다.
• 검색 엔진이 크롤링할 때 Javascript를 실행하지 않고 어플리케이션이 로드 되기 전의 코드를 크롤링 하기 때문에 인덱싱이 제대로 이루어지지 않아 검색엔진 최적화가 어렵다.

SPA 그림.

아래 종민불님 블로그 참고

https://jongminfire.dev/spa-single-page-application-%EB%9E%80

1. 전역으로 사용자 이름과 이메일 설정하기

git conifg --global user.name "유저네임"
git config --global user.email "이메일주소"

2. 프로젝트 생성

자신이 사용할 프로젝트 파일을 init을 통해 초기화

git init

git init 명령어를 사용하면. git 폴더가 생성된다. 이는 숨긴 파일로 되어있기 때문에 window에서 숨긴 파일해제를 해야 볼 수 있다. 

3. GIT 설명

.git 은 특정폴더(. git)에 내가 작업한 히스토리를 모두 보관하는 프로그램이다.

이를 버전관리 시스템이라고 한다.

git이라는 폴더를 통해 작성한 코드들들의 시간과 기록을 히스토리로 저장하여 내가 원하는 지점과 작업에 에러가 생긴다면 에러가 나기 전의 시점으로 돌아갈 수 있는 아주 강력한 도구이다.

4. GIT 실습

git init을 진행 시킨 폴더에 

development.json 추가

{
    "username": "root",
    "password": "root",
    "database": "board_dev",
    "host": "127.0.0.1",
    "dialect": "mysql"
}

작업한 폴더에 json 파일을 추가한 후

깃 현재 상태 확인

git status

명령어 를 사용하면 자신이 추가한 파일이나 폴더를 추적하여 준다.

아래와 같이 git status 명령어를 쳤을 때 파일은 추가했지만, Untracked files에 빨간색으로 뜬다면, 워크스페이스 즉, 자신이 작업하던 공간에서 git add test.json 명령어를 통해 stage로 올려줘야 한다. 

깃 스테이지에 저장

git add test.json

깃 스테이지에 올라간 파일은  new file : test.json의 형태로 올라가게 되고, 이는 git repository에 올라갈 준비가 되었다. 

이 상태에서 git commit -m 'feat : add file test.json' 을 통해 자신이 기록할 커밋메시지로 커밋을 하게 되면, 자신이 올린 파일이 커밋 메시지와 함께 깃 repository에 올라가게 된다. 

깃 레포지토리에 올리기 및 커밋메시지 남기기 

git commit -m 'feat : add file test.json'

커밋 메시지를 남기게 되면 레포지토리에 파일이 올라가면서 커밋메시지를 남기게 된다. 

깃 로그 

git log

깃 로그 명령어를 치게 되면 자신이 작성한 깃 로그를 확인 할 수 있다.

commit 뒤에는 해시값이 나오게 되고 이 해 시값을 통해 자신의 commit에 대해 접근할 수 있다.

Author 에는 자신이 등록했던 유저 네임과 유저 이메일이 뜬다. 

맨 아래에는 feat : add file test.json 이 자신이 기록한 커밋메시지가 남게 된다. 

5. 기본적인 깃 사용 정리 

1. 전역으로 사용자 이름과 이메일 설정하기

git conifg --global user.name "유저네임"
git config --global user.email "이메일주소"

2. 프로젝트 생성

사용할 폴더에 깃 초기화

git init

3. 깃 상태 확인

git status

4.  워크스 페이스에 파일 추가하기 

test.json 파일 추가하기

5. 깃 파일 스테이지에 추가하기 

git add test.json

6. 깃 레포지토리에 올리기 및 커밋메시지 남기기 

git commit -m 'feat : add file test.json'

7. 깃 로그로 자신이 남긴 커밋메시지 및 내용확인

git log

깃 이란 용어는 개발을 하면서 가장 많이 듣는 용어중 하나이다. 컴퓨터공학과에서 깃을 여러번 써 보았지만, 완벽한 이해없이 당연시하게 사용했던 경우가 많았다. 이를 보충하기 위해 깃을 왜 쓰고 깃을 어떻게 쓰는 지 공부하였다. 오늘은 깃을 설치하는 과정에 대해 알아 보겠다. 

1. 깃 설치하기 

 1-1) WINDOW 기준 :

GIT 공식홈페이지 접속 : https://gitscm.com

설치과정중 Git Bash를 반드시 포함!!

git --version

명령어가 실행 될 시 git 설치완료 / 안될 시 재설치

1-2) 리눅스 깃 설치하기 :

$ sudo apt install git
$ git --version

깃 설치 완료시 git --version을 치면 깃의 버전을 확인할 수 있다.

job 이란 객체가 어떤 식으로 할당되고 저장되는지 생각해 보자. 

const job = {
  job: "senior developer",
  career: "10",
  ageGroup: {
    group: 30,
    person: {
      name: "ingoo",
      id: "web7722",
    },
  },
};

위와 같이

1. job 객체 내부에는 job, career, agerGroup의 키값으로 프로퍼티들이 저장돼있다. 

2. ageGroup 안에는 키 값으로 group 과 person으로 프로퍼티들이 저장돼있다.

3. person 안에는 키 값으로 name과 id 가 프로퍼티로 저장돼있다. 

이때 어떠한 방식으로 데이터가 저장되는지 확인해 보자. 

첫 번째로 job 객체가 생성되면 job 객체는 영역을 할당하고 영역은 키값으로 job, career, ageGroup 으로 나뉜다. 각각의 키값들은 각각의 키에 대한 value 값을 저장하기 위해 값을 저장한 주소를 가리키는데 원시타입 job의 데이터는 senior developer로 원시타입 String, career는 10으로 원시타입 Number 데이터를 가지고 있기 때문에 할당된 주소에 값들을 저장한다. 

 둘째로 ageGroup의 경우 데이터를 할당하기 위해 0x4번지에 객체를 할당하고 그 객체의 내부는 또 키값인 group과 person으로 나뉘고, group의 경우 원시타입 Number로 30을 저장하기 때문에 0x5번지에 30을 저장하고, person의 경우 또 객체를 저장하고 있기 때문에 0x6번지에 객체를 저장하게 된다. 객체의 내부에는 name, id 의 키값을 가지고 있고, 최종적으로 ingoo와 web7722 의 String 원시데이터 타입을 가지고 있기때문에 더 이상 주소할당을 하지 않게 된다. 이 처럼 자바 스크립트는 객체가 생성될 때 프로퍼티의 타입에 따라 할당되는 값과 번지수 들이 다르고 원시타입의 데이터 이외의 타입들은 참조 타입이라 불리고 위와 같이 객체와 같은 참조 타입들은 어떠한 데이터를 넣느냐에 따라 동적으로 데이터의 크기가 변할 수 있다. 

이로써 알 수 있는 것은 원시타입 데이터를 저장하는 것은 데이터의 크기가 변하지 않고, 이와 반대로 참조타입의 데이터들은 동적으로 크기가 변할 수 있다는 것이다. 또한 참조타입의 데이터의 경우 참조될 주소값으로 저장되기 때문에 주소값을 참조하여 타고 들어가 데이터 값들을 가져올 수 있다. 

위와 같이 변수 안에 직접값을 넣지 않고, 데이터값을 참조하는 참조주소값을 넣는 이유는 메모리를 효율적으로 사용하기 위해서 이다. 만일 0x3번지의  데이터값이  10이라는 숫자에서 객체로 바뀐다면 할당되는 공간의 크기가 바뀌기 때문에 이를 찾아서 재할당하기 위해 크기를 늘리는 작업을 해야하지만, 0x3번의 참조 주소값을 지우고, 0x9번지에 객체데이터를 넣게 되면 참조되는 주소값을 바꿈으로써 쉽게 할당할 수 있다.  이때 0x3 번지의 주소가 끊기고 이는 자바스크립트의 가비지 컬렉터가 자동적으로 메모리 할당을 해제 시킨다. 이처럼 변하는 데이터타입에 따라 할당 공간과 크기가 달라지기 때문에 자바스크립트는 직접적으로 값을 저장하지 않고 참조값형태로 데이터를 저장한다.