Blockchain II (Block height, fork - блокийн өндөр, салаа блокууд)

Блок-ын өндөр, салаа блок(ууд)

(хяналт хийж бна...)
Блок-ын толгойн хэсэгийн хашийг тоон хязгаараас доош утгаар амжилттай хаш хийсэн ямар ч уурхайчин нь, тухайн блок нь хүчинтэй тохиолдолд гинжэлсэн блокууд руу нэмж болно. Эдгээр блокууд нь блок-ын "өндөр"-тэй байх бөгөөд энэ нь хамгийн эхний блок No.0 болох генесис блок болон тухайн блок хоёрын хооронд хийгдсэн блокуудын тоогоор илэрхийлэгдэнэ. 

Жишээ нь хамгийн эхний блокд хаш тайлах хэр хэцүүг дахин тодорхойлсон блок нь 2016-р блок болно. 

Хэд хэдэн блокууд ижилхэн "өндөр"-тэй байх тохиолдолд байж болох бөгөөд эдгээр нь нэгээс илүү уурхайчинд алилхан буюу ойролцоо цаг мөчид зэрэг блок бүтээсэн тохиолдолд байж болно. Ингэснээр гинжилсэн блокуудад салаалалт (fork) үүсэх боломжтой. (Дээрх зураг дээр харуулснаар).

Хэрэв энэ тохиолдолд зэрэг өндөртэй блокуудаас сүлжээнд оролцож буй зангилаа бүр аль блокийг сонгох сонголт хийх хэрэгтэй болно. Ямар нэгэн өөр дүрэм бичигдээгүй тохиолдолд ихэнхдээ зангилаанд хүрж ирсэн эхний блокийг сонгоно.

Эцэстээ уурхайчин дахин блок үүсгэн түүнийгээ түрүүчийн хэсэгт зэрэг хийгдсэн блокуудын аль нэгт нь залгах хэрэгтэй болно. Ингэснээр тухайн залгасан блокийн үүсгэсэн салаа нь бусад салаалалтаасаа илүү хүчинтэй болно. Тухайн салаалалт дахь орших блокууд хүчинтэй л бол уурхайчид хамгийн их хүч чармайлт нэхэгдэх салаалалтыг дагаснаар бусад салаанууд хүчингүй болно. Эдгээр бусад салааг нь stale блок, өнчин (orphan) блок гэх мэтээр олон янзаар нэрлэгддэг. Зарим тохиололд жинхэнэ өнчин блок гэж байх бөгөөд энэ нь өмнөх блок нь устсан буюу байхгүй тохиолдолд ингэж нэрлэгдэнэ.

Зарим тохиолдолд салаалалт нь удаан хугацаагаар оршин тогтнох үе байдаг бөгөөд энэ нь уурхайчид тухайн салаалалтыг цаашин үргэлжлүүлж ажилладаг. Энэ үед бусад уурхайчид 51%-ын халдалт хийх оролдлого хийж байж болно.

Нэгээс илүү блокууд нь адилхан өндөртэй байх боломжтой тул блокын өндрөөр нь таних тэмдэг болгох нь тохиромжгүй юм. Харин үүний оронд блокын таних тэмдэгийг толгойн тэмдэглэгээний хаш утгаар нь дуудан, заах нь илүү тохиромжтой.

Гүйлгээний мэдээлэл

Блок бүр нь нэг буюу түүнээс дээш гүйлгээг хадгалж байдаг. Эдгээр гүйлгээний хамгийн эхнийх нь үндсэн зоосон (coinbase, a.k.a generation transaction) гүйлгээ гэж нэрлэгдэх бөгөөд энэ нь гүйлгээ нь блок хийгдсэн шагналыг хуримтлуулж, зарцуулах зориулалттай байна. Блок хийгдсэн шагнал нь гүйлгээний шимтгэл болон блок хөнгөлөлт (block subsudy) зэргээс бүрдэнэ. Дээр өгүүлсэнээр зарцуулагдаагүй гүйлгээ буюу UTXO (Unspent transaction Output) нь үндсэн зоосны гүйлгээ байсан тохиолдолд дараагийн 100 блокт зарцуулагдах боломжгүй байна. Ингэснээр тухайн блок салаалан, салаалсны дараа хүчингүй болсон тохиолдолд уурхайчинг шагнах боломжгүй бөгөөд хүчингүй болохоос өмнө уурхайчин шимтгэлийг зарцуулахаас сэргийлнэ.
Блок нь үндсэн бус гүйлгээ (non-coinbase transaction)-г агуулах шаардлагагүй боловч уурхайчид аль ч тохиолдолд үндсэн бус гүйлгээг блокт багтаадаг ба ингэснээрээ шагнал хүртэх боломжтой болно. Бүх гүйлгээнүүд нь (үндсэн гүйлгээ ч адил) блокт түүхий тэмдэглэгээ  форматаар (raw transaction format) болон үлдэнэ.
Түүхий гүйлгээний формат нь гүйлгээний таних тэмдэг-(transaction identifier) ийг бүтээхэд ашиглагддаг. Эдгээр форматыг ашиглан, merkle мод (tree) үүсгэнэ. Merkle модыг хоёр гүйлгээний таних тэмдгүүдийг нийлүүлсний дараа хаш хийж түүнийгээ дахин өөр адилхан замаар хийсэн хаш-тай нийлүүлэн дахин хаш хийх маягаар үүсгэнэ. Хэрэв гүйлгээнүүдийн тоо нь сондгой утгатай байсан тохиолдолд, тухайн сондгойрсон гүйлгээний таних тэмдэгт ганцаар хаш хийж өөртэй хаштай нийлүүлнэ. Энэ замаар хаш-уудыг нийлүүлж хаш хийгдсээр эцэстээ нэг хаш үлдэх бөгөөд үүнийг merkle модны үндэс гэж нэрлэнэ (merkle root).
Жишээ нь 5 гүйлгээнээс бүрдсэн merkle мод болон түүний үндэс хийгдэх зургийг дор харуулав:
       ABCDEEEE .......Merkle үндэс

      /        \
   ABCD        EEEE
  /    \      /
 AB    CD    EE .......E нь сондгой учир 2 дахин давтаж түүн дээрээ хаш хийнэ.
/  \  /  \  /
A  B  C  D  E .........гүйлгээнүүд

SPV буюу хялбаржуулсан төлбөрийн баталгаажуулалт нь merkle модыг ашиглаж хийгдэнэ. Ингэхдээ client системүүдэд гүйлгээ нь блокт байрлуулсаныг шалгахын тулд блокын толгойн хэсэг дэх merkle үндсэн хаш болон,  зэргэлдээх бүрэн хэмжээний системүүд-(full peer)-ээс дундын хаш-уудын жагсаалтыг ашиглан шалгалт хийнэ. Зэргэлдээх бүрэн хэмжээний системд итгэх эсэх шаардлага гарахгүй учир нь хуурамч блокийн толгойн тэмдэглэгээ болон дундын хаш-уудыг гаргах үнэ өртөг нь өндөр байна эс бөгөөс шалгалт нь буруу гарна.

Жишээ нь, гүйлгээ D блокт нэмэгдсэнийг шалгая гэж бодьё, тэгсэн тохиолдолд SPV буюу хялбаршуулсан шалгалт хийж буй client нь C, AB болон EEEE хашуудыг merkle үндэсэн хаш-тай хамт хэрэглэн шалгалт хийнэ, өөр ямарваа нэгэн мэдээлэл хэрэггүй болно. Хэрвээ эдгээр 5-н гүйлгээг агуулсан блокуудыг бүгдийг хуулан авахад 500,000-аас илүү byte шаардлагатай болно. Харин зөвхөн хаш болон блокийн эхэн тэмдэглэлийг ашигласнаар зөвхөн 140 byte download хийх шаардлагатай.

Жич: Хэрэв нэг блок дотор адил таних тэмдэг олдсон тохиолдолд, merkle мод нь өөр блоктой зөрчилдөх талтай, учир нь тухайн өөр блокоос зарим эсвэл бүх давхар тэмдэглэгээнүүдийг хассан байж болох талтай. Ингэж хасагдсан шалтгаан нь тэнцвэргүй merklee мод үүсэх нөхцлийг бүрдүүлэх талтай.

Адил таних тэмдэгтэй тусдаа гүйлгээнүүд нь практикийн хувьд тохиромжгүй тул, шударга программ хангамжид энэ нь дараа болохгүй ба; харин блокийн хүчингүй статусыг хадгалах эсхийг шалгах хэрэгтэй. Ингэхгүй тохиолдолд, адилхан тэмдэглэгээтэй хэсгийг нь устгасан хүчинтэй блок нь адил merkle үндсэн хаш болон блок хаштай байж болох бөгөөд, энэ хүчинтэй блок нь хадгалсан хүчингүй блокийн улмаас хүчингүй болох боломжтой юм. (CVE-2012-2459)

Зөвшилцлийн дүрэмийг өөрчлөх

Сүлжээнд буй зангилаанууд зөвшилцлийн байдалд оршихын тулд бүгд ижил зөвшилцлийн дүрэм ашиглан блок-т шалгалт хийнэ. Зарим тохиолдолд шинээр нэмэлт шаардлагатай өөрчлөлт болон сүлжээг зүй бусаар ашиглахаас хамгаалсан өөрчлөлтүүд хэрэгтэй болж "зөвшилцлийн дүрэмд" өөрчлөлт оруулах шаардлагатай болно. Энэ тохиолдолд шинээр өөрчлөлт хийсний дараа түр хугацаанд зарим зангилаанууд нь хуучин дүрмийг ашигласаар байх тохиолдолд бий бөгөөд энэ нь дараах 2 янзаар "зөвшилцлийн дүрэм" зөрчигдөх болно:
1. Шинэ зөвшилцлийн дүрмээр бүтээгдсэн блок-ийг шинэ upgrade хийсэн зангилаанууд хүлээн авч, хуучин дүрмээр ажиллаж буй зангилаанууд хүлээн авахаас татгалзах болно.
2. Хуучин зөвшилцлийн дүрмээр бүтээгдсэн блок-ийг хуучин дүрмээр ажиллаж буй зангилаанууд хүлээн авч шинээр upgrade хийж шинэ дүрмээр ажиллаж буй зангилаанууд хүлээн авахаас татгалзана.

Эхний тохиолдолд, хуучин дүрмээр ажиллаж буй зангилаанууд нь шинэ дүрмээр бүтээгдсэн блокууд-ыг хүлээн авалгүйгээр хуучин блокоос бүрдсэн салаалалт үүсгэж эхэлнэ. Энийг hard fork буюу хатуу салаалалт гэж нэрлэнэ.

Хоёр дахь тохиолдолд upgrade хийсэн зангилаанууд нь хаш-уудын ихэнхийг хийж эхэлсэн тохиолдолд салаалалт үүсгэхээс сэргийлж болно. Үүний тулд upgrade хийгээгүй хуучин дүрмээр ажиллаж буй программууд нь аль ч шинэ блокийг upgrade хийсэн зангилаанаас татгалзалгүй хүлээн авна. Энэ тохиолдолд үүссэн салаалалтыг soft fork буюу зөөлөн салаалалт гэнэ.

Үүнээс үүдэн зөвшилцлийн дүрэмд өөрчлөлт хийх нь хатуу эсвэл зөөлөн салаалалт хийх магадлалыг буй болгоно. Жишээ нь блок-ын хэмжээг 1mb-аас дээш болгох зөвшилцлийн дүрмийн өөрчлөлт хатуу салаалалт бий болгох нь зайлшгүй юм. Энэ тохиолдолд яг гинжэн блокийн салаалалт заавал хэрэггүй гэхдээ болзошгүй зүйл юм??

Нэмэль мэдээллүүд: BIP16, BIP30, мөн BIP34 өөрчлөлтүүд нь зөөлөн салаалалт хийгдэж болзошгүй дүрмийн өөрчлөлтүүд юм.BIP50-д харин хатуу салаалалт санаандгүй үүссэн бөгөөд үүнийг түр хугацаанд upgrade хийгдсэн зангилаануудыг буцаан түр хугацаанд downgrade хийж зохиомол хатуу салаалалт үүсгэж шийдвэрлэсэн.
Гэвин Андрэсэн-ий дараах нийтлэл нь ирээдүйд хийгдэх дүрмийн өөрчлөлтүүд хэрхэн хийгдэхийг тайлбарласан байна: how future rule changes may be implemented.

Салаалалтыг нээж илрүүлэх

Upgrade хийгээгүй зангилаанууд нь хуучин дүрмээр хэсэг хугацаанд ч болов блок-уудыг үүсгэн энэнээс үүдэн хөрөнгө мөнгөний алдагдал гарах хэд хэдэн нөхцөл байдлыг үүсгэдэг. Ялангуяа хуучин зангилаанууд нь гүйлгээг хүлээн авч боловсруулсан ч түүнээс үүдсэн блокууд нь нийтээр хүлээн зөвшөөрөгдөх гинжэн блок-т хамрагдах боломжгүй болж болно. Мөн хуучин зангилаанууд нь гинжэн блокт хийгдсэн гүйлгээнүүдийг хүлээн авалгүйгээр дутуу мэдээлэл үүсгэж болно. 

Bitcoin Core нь гинжэн блок дахь гүйцэтгэлийн батламжийн мэдээллийг ашиглан хатуу салаалалтыг олж илрүүлэхээр бичигдсэн байдаг. Хэрэв upgrade хийгээгүй зангилаа нь хамгийн сайн гинжэн салаанаас 6-н блокоор илүү гүйцэтгэлийн баталгаатай блокийн толгой хэсгийг хүлээн авсан тохиолдолд, зангилаа нь getinfo RPC -д алдаа зааж alertnotify коммандыг гүйцэтгэнэ. Ингэснээр upgrade хийгээгүй зангилаа нь операторт хамгийн сайн гинжэн блок руу шилжих боломжгүй байгааг анхааруулна.

Бүрэн хэмжээний зангилаа нь мөн блок болон гүйлгээний version-ыг заасан дугаарыг мөн шалгаж болно. Хэрэв сүүлийн хэдэн блокуудын version дугаар нь түрүүчийн блокуудынхаас ахисан тохиолдолд, одоо хэрэглэгдэж буй зөвшилцлийн дүрмийг хэрэглэж болохгүй гэж ойлгож болно. Bitcoin core 0.10.0 нь үүнийг getinfo RPC болон alertnotify мэдээлж болно.

Зөвхөн version дугаарыг ашиглах нь мөн хангалтгүй байж болох ба учир нь блок болон гүйлгээний мэдээлэл нь upgrade хийгээгүй (шинээр өөрчилсөн зөвшилцлийн дүрэмийг ашиглаагүй) зангилаанаас ирсэн байж болох талтай юм. SPV буюу хялбарчилсан гүйлгээний шалгалт хийж буй client нь хэд хэдэн бүрэн хэмжээний зангилаатай холбогдон тэдгээр нь бүгд адил гинжэн дээр болон адилхан блокийн өндөр дээр байгаа эсэхийг шалган хатуу салаалалт үүссэн эсэхийг мэдэж болно. Аль нэг зангилаанд хазайлт үүссэн (тухайн зангилаа нь өөр салаан дээр ажиллаж буй тохиолдолд) SPV client нь тухайн зангилаанаас холбоогоо тасалж болно.
SPV client-үүд мөн блок болон гүйлгээний version дугаарыг хянаж, ирсэн гүйлгээнүүдийг шинэ зөвшилцлийн дүрмээр шинэ гүйлгээ хийх хэрэгтэй.