හෙලෝ, මම DRD KP ව්‍යාපෘතියේ කණ්ඩායමේ වැඩ කරමි (රෝද කට්ටලවල ජීවන චක්‍රය නිරීක්ෂණය කිරීම සඳහා බෙදා හරින ලද දත්ත රෙජිස්ට්‍රිය). තාක්‍ෂණයේ සීමාවන් යටතේ මෙම ව්‍යාපෘතිය සඳහා ව්‍යවසාය අවහිර කිරීමක් සංවර්ධනය කිරීමේදී අපගේ කණ්ඩායමේ අත්දැකීම් මෙහි බෙදා ගැනීමට මම කැමැත්තෙමි. බොහෝ දුරට, මම Hyperledger Fabric ගැන කතා කරනු ඇත, නමුත් මෙහි විස්තර කර ඇති ප්‍රවේශය ඕනෑම අවසර ලත් බ්ලොක්චේන් එකකට විකාශනය කළ හැකිය. අපගේ පර්යේෂණයේ අවසාන ඉලක්කය වන්නේ අවසාන නිෂ්පාදනය භාවිතා කිරීමට ප්‍රසන්න වන පරිදි සහ නඩත්තු කිරීමට අපහසු නොවන ආකාරයට ව්‍යවසාය අවහිර කිරීමේ විසඳුම් සකස් කිරීමයි.
සොයාගැනීම්, අනපේක්ෂිත විසඳුම්, සහ අද්විතීය වර්ධනයන් මෙහි ආවරණය නොවනු ඇත (මා සතුව ඒවා නොමැති නිසා). මට අවශ්ය වන්නේ මගේ නිහතමානී අත්දැකීම බෙදා ගැනීමට, "එය කළ හැකි වූවක්" බව පෙන්වීමට සහ, සමහර විට, අදහස් දැක්වීමේදී හොඳ සහ එතරම් හොඳ නොවන තීරණ ගැනීමේ වෙනත් කෙනෙකුගේ අත්දැකීම් ගැන කියවීමට ය.
ගැටලුව: blockchains තවමත් පරිමාණය කළ නොහැක
අද, බොහෝ සංවර්ධකයින්ගේ උත්සාහයන් බ්ලොක්චේන් සැබවින්ම පහසු තාක්‍ෂණයක් බවට පත් කිරීම අරමුණු කර ගෙන ඇති අතර අලංකාර එතුමක ටික් කරන කාල බෝම්බයක් නොවේ. රාජ්ය නාලිකා, ශුභවාදී රෝල්අප්, ප්ලාස්මා සහ ෂර්ඩින් සාමාන්ය දෙයක් විය හැක. යම් දවසක. නැතහොත් TON නැවතත් මාස හයකට දියත් කිරීම කල් දමනු ඇති අතර ඊළඟ ප්ලාස්මා සමූහය නොපවතිනු ඇත. අපට වෙනත් මාර්ග සිතියමක් විශ්වාස කළ හැකි අතර රාත්‍රියේ දීප්තිමත් සුදු පත්‍රිකා කියවිය හැකිය, නමුත් මෙන්න සහ දැන් අප සතුව ඇති දේ සමඟ යමක් කළ යුතුය. ජරාව හදාගන්න.
වත්මන් ව්‍යාපෘතියේ අපගේ කණ්ඩායමට පවරා ඇති කාර්යය සාමාන්‍යයෙන් පෙනෙන්නේ මේ ආකාරයට ය: විශ්වාසය මත සබඳතා ගොඩනඟා ගැනීමට අකමැති බොහෝ විෂයයන් දහස් ගණනක් කරා ළඟා වේ; විශේෂ කාර්ය සාධන අවශ්‍යතා නොමැතිව සාමාන්ය පරිගණකවල ක්‍රියා කරන සහ ඕනෑම මධ්‍යගත ගිණුම්කරණ පද්ධතියකට වඩා නරක නොවන පරිශීලක අත්දැකීමක් ලබා දෙන විසඳුමක් DLT මත ගොඩනැගීම අවශ්ය වේ. විසඳුම පිටුපස ඇති තාක්ෂණය අනිෂ්ට දත්ත හැසිරවීමේ හැකියාව අවම කළ යුතුය - බ්ලොක්චේන් මෙහි ඇත්තේ එබැවිනි.
ධවල පත්‍රිකා සහ මාධ්‍යවල සටන් පාඨ අපට පොරොන්දු වන්නේ මීළඟ සංවර්ධනය තත්පරයකට මිලියන ගණනක ගනුදෙනුවලට ඉඩ ලබා දෙන බවයි. ඇත්තටම එය කුමක්ද?
Mainnet Ethereum දැනට ~30 tps හි ධාවනය වේ. මේ නිසාම, එය ආයතනික අවශ්‍යතා සඳහා ඕනෑම ආකාරයකින් සුදුසු බ්ලොක්චේන් එකක් ලෙස වටහා ගැනීම දුෂ්කර ය. අවසර ලත් විසඳුම් අතර, 2000 tps පෙන්වන මිණුම් සලකුණු දනී () හෝ 3000 tps (, ප්‍රකාශනයේ ටිකක් අඩුයි, නමුත් මිණුම් ලකුණ පැරණි එකඟතා එන්ජිම මත සිදු කළ බව මතක තබා ගන්න). විය , නරකම ප්‍රතිඵල ලබා නොදුන්, tps 20000, නමුත් මෙතෙක් මේවා ඔවුන්ගේ ස්ථාවර ක්රියාත්මක කිරීම සඳහා බලා සිටින ශාස්ත්‍රීය අධ්‍යයන පමණි. බ්ලොක්චේන් සංවර්ධකයින්ගේ දෙපාර්තමේන්තුවක් නඩත්තු කිරීමට හැකි සංස්ථාවක් එවැනි දර්ශක සමඟ කටයුතු කරනු ඇතැයි සිතිය නොහැක. නමුත් ගැටලුව ප්‍රතිදානයේ පමණක් නොව, ප්‍රමාදය ද ඇත.
කාලගුණය
ගනුදෙනුවක් ආරම්භ කළ මොහොතේ සිට පද්ධතිය විසින් එහි අවසාන අනුමැතිය දක්වා ප්‍රමාදය රඳා පවතින්නේ වලංගු කිරීමේ සහ ඇණවුම් කිරීමේ සියලුම අදියරයන් හරහා ගමන් කරන පණිවිඩයේ වේගය මත පමණක් නොව, බ්ලොක් සෑදීමේ පරාමිතීන් මත ය. අපගේ blockchain අපට tps 1000000 කින් කැපවීමට ඉඩ දුන්නද, නමුත් 10MB බ්ලොක් එකක් සෑදීමට මිනිත්තු 488ක් ගත වුවද, එය අපට පහසු වේවිද?
Hyperledger Fabric හි ගනුදෙනුවක ජීවන චක්‍රය දෙස සමීපව බලමු, කාලය ගත වන්නේ කුමක්ද සහ එය අවහිර සෑදීමේ පරාමිතීන්ට සම්බන්ධ වන්නේ කෙසේද යන්න තේරුම් ගැනීමට.
මෙතනින් ගත්තේ:
(1) සේවාලාභියා ගනුදෙනුවක් සාදා, එය අනුමත කරන මිතුරන් වෙත යවයි, දෙවැන්න ගනුදෙනුව අනුකරණය කරයි (දාම කේතය මඟින් සිදු කරන ලද වෙනස්කම් වත්මන් තත්වයට යොදන්න, නමුත් ලෙජරයට කැප නොවන්න) සහ RWSet - ප්‍රධාන නම්, අනුවාද සහ CouchDB හි එකතුවෙන් ලබාගත් අගයන්, (2) අනුමත කරන්නන් විසින් අත්සන් කරන ලද RWSet නැවත සේවාදායකයා වෙත යවයි, (3) සේවාලාභියා එක්කෝ අවශ්ය සියලුම මිතුරන්ගේ (අනුමත කරන්නන්ගේ) අත්සන් සඳහා පරීක්ෂා කර පසුව ගනුදෙනුව ඇණවුම් කිරීමට යවයි සේවාව, හෝ එය සත්‍යාපනයකින් තොරව යවයි (සත්‍යාපනය තවමත් පසුව සිදුවනු ඇත), ඇණවුම් කිරීමේ සේවාව බ්ලොක් එකක් සාදන අතර (4) අනුමත කරන්නන් පමණක් නොව සියලුම මිතුරන් වෙත ආපසු යවයි; කියවීම් කට්ටලයේ යතුරුවල අනුවාද දත්ත ගබඩාවේ ඇති අනුවාද, සියලුම අනුමත කරන්නන්ගේ අත්සන් සමඟ ගැළපෙන බව සම වයසේ මිතුරන් පරීක්ෂා කර අවසානයේ අවහිර කිරීම සිදු කරයි.
නමුත් එය පමණක් නොවේ. “ඇණවුම්කරු අවහිරයක් සාදයි” යන වචන පිටුපස ගනුදෙනු ඇණවුම් කිරීම පමණක් නොව, නායකයාගෙන් අනුගාමිකයින්ට සහ පසුපසට අඛණ්ඩ ජාල ඉල්ලීම් 3 ක් ද සැඟවී ඇත: නායකයා ලොගයට පණිවිඩයක් එක් කරයි, අනුගාමිකයින්ට යවයි, දෙවැන්න එකතු කරන්න ඔවුන්ගේ ලඝු-සටහන, සාර්ථක ප්‍රතිනිර්මාණයක් නායකයාට යවන්න, නායකයා පණිවිඩය කරයි, අනුගාමිකයින්ට කැපවීම තහවුරු කිරීම යවයි, අනුගාමිකයින් කැපවෙයි. බ්ලොක් ප්රමාණය සහ වේලාව කුඩා වන තරමට ඇණවුම් කිරීමේ සේවාවට එකඟතාවයක් ඇති කිරීමට සිදුවේ. Hyperledger Fabric හට වාරණ සෑදීමේ පරාමිති දෙකක් ඇත: BatchTimeout - වාරණ සෑදීමේ කාලය සහ BatchSize - වාරණ ප්රමාණය (ගනුදෙනු ගණන සහ බ්ලොක් එකේ ප්රමාණය බයිට් වලින්). එක් පරාමිතියක් සීමාවට ළඟා වූ වහාම නව බ්ලොක් එකක් නිකුත් කරනු ලැබේ. ඇණවුම් නෝඩ් වැඩි වන තරමට මෙයට වැඩි කාලයක් ගතවනු ඇත. එමනිසා, ඔබ BatchTimeout සහ BatchSize වැඩි කළ යුතුය. නමුත් RWSets අනුවාදය කර ඇති බැවින්, අපි අවහිර කිරීම විශාල වන තරමට, MVCC ගැටුම්වල සම්භාවිතාව වැඩි වේ. ඊට අමතරව, BatchTimeout වැඩි වීමත් සමඟ, UX විනාශකාරී ලෙස පිරිහී යයි. මෙම ගැටළු විසඳීම සඳහා පහත යෝජනා ක්‍රමය සාධාරණ සහ පැහැදිලි බව මට පෙනේ.
වාරණ අවසන් කිරීම සඳහා බලා සිටීම වළක්වා ගන්නේ කෙසේද සහ ගනුදෙනු තත්ත්වය පිළිබඳ වාර්තාවක් නැති කර ගන්නේ කෙසේද
ගොඩනැගීමේ කාලය සහ බ්ලොක් ප්රමාණය වැඩි වන තරමට බ්ලොක්චේන් ප්‍රතිදානය වැඩි වේ. එකක් අනෙකාගෙන් කෙලින්ම අනුගමනය නොකරයි, නමුත් RAFT හි සම්මුතියක් ඇති කර ගැනීම සඳහා නායකයාගෙන් අනුගාමිකයින්ට සහ පසුපසට ජාල ඉල්ලීම් තුනක් අවශ්ය බව මතක තබා ගත යුතුය. වැඩි ඇණවුම් නෝඩ්, එය වැඩි කාලයක් ගතවනු ඇත. බ්ලොක් සෑදීමේ ප්රමාණය හා කාලය කුඩා වන තරමට එවැනි අන්තර්ක්‍රියා වැඩි වේ. අවසාන පරිශීලකයා සඳහා පද්ධති ප්‍රතිචාර කාලය වැඩි නොකර ගොඩනැගීමේ කාලය සහ අවහිර ප්රමාණය වැඩි කරන්නේ කෙසේද?
පළමුව, ඔබට විශාල බ්ලොක් ප්‍රමාණයකින් ඇති වන MVCC ගැටුම් කෙසේ හෝ විසඳා ගත යුතු අතර, එකම අනුවාදය සමඟ විවිධ RWSets ඇතුළත් විය හැක. නිසැකවම, සේවාලාභියාගේ පැත්තෙන් (බ්ලොක්චේන් ජාලයට සාපේක්ෂව, මෙය පසුබිමක් විය හැකි අතර, මම එය අදහස් කරමි) MVCC ගැටුම් හසුරුවන්නා, එය වෙනම සේවාවක් හෝ නැවත උත්සාහ කිරීමේ තර්කනය සමඟ ගනුදෙනු-ආරම්භක ඇමතුමක් හරහා සාමාන්ය සැරසිලි කරුවෙකු විය හැකිය.
නැවත උත්සාහ කිරීම ඝාතීය උපාය මාර්ගයකින් ක්රියාත්මක කළ හැක, නමුත් එවිට ප්‍රමාදය ඝාතීය ලෙසද පිරිහෙනු ඇත. එබැවින් ඔබ යම් යම් කුඩා සීමාවන් තුළ සසම්භාවී නැවත උත්සාහයක් හෝ නියත එකක් භාවිතා කළ යුතුය. පළමු ප්‍රභේදයේ ඇති විය හැකි ඝට්ටන පිළිබඳ ඇසකින්.
මීළඟ පියවර වන්නේ, තත්පර 15, 30, හෝ 10000000 ක් බලා නොසිටීම සඳහා සේවාලාභියාගේ පද්ධතිය සමඟ අන්තර්ක්‍රියා අසමමුහුර්ත කිරීමයි, එය අපි BatchTimeout ලෙස සකසන්නෙමු. නමුත් ඒ සමඟම, ගණුදෙණුවෙන් ආරම්භ කරන ලද වෙනස්කම් බ්ලොක්චේන් තුළ වාර්තා කර ඇති / වාර්තා නොවන බවට වග බලා ගැනීමේ හැකියාව රඳවා තබා ගැනීම අවශ්ය වේ.
ගනුදෙනුවල තත්ත්වය ගබඩා කිරීම සඳහා දත්ත සමුදායක් භාවිතා කළ හැකිය. භාවිතයේ පහසුව නිසා පහසුම විකල්පය CouchDB වේ: දත්ත සමුදායේ කොටුවෙන් පිටත UI එකක්, REST API එකක් ඇත, ඔබට පහසුවෙන් එය අනුකරණය සහ බෙදා හැරීම සැකසිය හැක. Fabric එහි ලෝක තත්වය ගබඩා කිරීමට භාවිතා කරන CouchDB අවස්ථාවේදීම ඔබට වෙනම එකතුවක් සෑදිය හැක. අපි මේ ආකාරයේ ලේඛන ගබඩා කළ යුතුයි.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}ගනුදෙනුව සම වයසේ මිතුරන් වෙත යැවීමට පෙර මෙම ලේඛනය දත්ත ගබඩාවට ලියා ඇත, මෙය නිර්මාණය කිරීමේ මෙහෙයුමක් නම්, ආයතන හැඳුනුම්පත පරිශීලකයා වෙත ආපසු ලබා දෙනු ලැබේ (එකම ID යතුරක් ලෙස භාවිතා කරනු ලැබේ), පසුව තත්ත්වය, TxID සහ දෝෂ ක්ෂේත්‍ර වේ. සම වයසේ මිතුරන්ගෙන් අදාළ තොරතුරු ලැබෙන පරිදි යාවත්කාලීන වේ.
මෙම යෝජනා ක්‍රමයේදී, පරිශීලකයා අවසානයේ බ්ලොක් එක සෑදීමට බලා නොසිටින අතර, තත්පර 10 ක් තිරය මත කැරකෙන රෝදය නරඹමින්, ඔහුට පද්ධතියෙන් ක්ෂණික ප්‍රතිචාරයක් ලැබෙන අතර දිගටම වැඩ කරයි.
අපට මතකය සුරැකීමට අවශ්ය නිසාත්, ස්වාධීන දත්ත සමුදා සේවාදායකයක් සමඟ ජාල අන්තර්ක්‍රියා සඳහා කාලය නාස්ති කිරීමට අවශ්ය නැති නිසාත්, විශේෂයෙන්ම මෙම අන්තර්ක්‍රියා සාමාන්ය පෙළ ප්‍රොටෝකෝලය භාවිතයෙන් සිදුවන විට ගනුදෙනු තත්ව ගබඩා කිරීමට අපි BoltDB තෝරා ගත්තෙමු. මාර්ගය වන විට, ඔබ ඉහත විස්තර කර ඇති යෝජනා ක්‍රමය ක්රියාත්මක කිරීමට CouchDB භාවිතා කළත් හෝ ලෝක රාජ්‍යය ගබඩා කිරීමට පමණක් භාවිතා කළත්, ඕනෑම අවස්ථාවක, CouchDB හි දත්ත ගබඩා කර ඇති ආකාරය ප්රශස්ත කිරීම අර්ථවත් කරයි. පෙරනිමියෙන්, CouchDB හි, b-tree nodes ප්රමාණය බයිට් 1279 ක් වන අතර එය තැටියේ ඇති අංශ ප්‍රමාණයට වඩා බෙහෙවින් අඩුය, එයින් අදහස් වන්නේ ගස කියවීම සහ නැවත සමතුලිත කිරීම යන දෙකටම වැඩි භෞතික තැටි ප්‍රවේශයන් අවශ්ය වන බවයි. ප්රශස්ත ප්රමාණය සම්මතය සපුරාලයි සහ කිලෝබයිට් 4 කි. ප්රශස්තකරණය සඳහා, අපි පරාමිතිය සැකසිය යුතුය btree_chunk_size 4096 ට සමාන වේ CouchDB වින්‍යාස ගොනුවේ. BoltDB සඳහා එවැනි අතින් මැදිහත් වීම .
පසුපස පීඩනය: බෆර් උපාය
නමුත් පණිවිඩ ගොඩක් තිබිය හැක. පද්ධතියට හැසිරවිය හැකි ප්‍රමාණයට වඩා, රූප සටහනේ පෙන්වා ඇති සේවාවන්ට අමතරව වෙනත් සේවාවන් දුසිමක් සමඟ සම්පත් බෙදාගැනීම - සහ මේ සියල්ල Intellij Idea ධාවනය කිරීම අතිශය වෙහෙසකර යන්ත්‍රවල පවා දෝෂ රහිතව ක්‍රියා කළ යුතුය.
සන්නිවේදන පද්ධති, නිෂ්පාදකයා සහ පාරිභෝගිකයාගේ විවිධ ප්‍රතිදානය පිළිබඳ ගැටළුව විවිධ ආකාරවලින් විසඳනු ලැබේ. අපි බලමු මොනවද කරන්න පුළුවන් කියලා.
හැලීම: අපට T තත්පර වලින් වැඩිම X ගනුදෙනු සැකසීමට හැකි බව ප්‍රකාශ කළ හැක. මෙම සීමාව ඉක්මවන සියලුම ඉල්ලීම් අත්හරිනු ලැබේ. එය ඉතා සරලයි, නමුත් එවිට ඔබට UX ගැන අමතක කළ හැකිය.
පාලනය කිරීම: පාරිභෝගිකයාට යම් අතුරු මුහුණතක් තිබිය යුතු අතර, බර අනුව, නිෂ්පාදකයාගේ tps පාලනය කළ හැකිය. නරක නැත, නමුත් මෙම අතුරුමුහුණත ක්රියාත්මක කිරීම සඳහා පැටවුම් සේවාලාභියාගේ සංවර්ධකයින් මත වගකීමක් පටවයි. අනාගතයේ දී බ්ලොක්චේන් දිගුකාලීන පද්ධති විශාල සංඛ්යාවක් ඒකාබද්ධ කරනු ලබන බැවින්, අප සඳහා, මෙය පිළිගත නොහැකි ය.
බෆරින් කිරීම: ආදාන දත්ත ප්‍රවාහයට ප්‍රතිරෝධය දැක්වීමට උත්සාහ කරනවා වෙනුවට, අපට මෙම ප්‍රවාහය බෆර කර අවශ්ය වේගයට එය ක්‍රියාවට නැංවිය හැකිය. නිසැකවම, අපට හොඳ පරිශීලක අත්දැකීමක් ලබා දීමට අවශ්ය නම් මෙය හොඳම විසඳුමයි. අපි RabbitMQ හි පෝලිමක් භාවිතයෙන් බෆරය ක්රියාත්මක කළෙමු.
යෝජනා ක්‍රමයට නව ක්‍රියා දෙකක් එකතු කර ඇත: (1) API ඉල්ලීමක් ලැබුණු පසු, ගනුදෙනුව ඇමතීමට අවශ්ය පරාමිති සමඟ පණිවිඩයක් පෝලිම් කර ඇති අතර, ගනුදෙනුව පද්ධතිය විසින් පිළිගෙන ඇති බවට පණිවිඩයක් සේවාදායකයාට ලැබේ, ( 2) පසුපෙළ පෝලිමේ සිට වින්‍යාසයෙහි දක්වා ඇති වේගයකින් දත්ත කියවයි; ගනුදෙනුවක් ආරම්භ කර තත්ව ගබඩාවේ දත්ත යාවත්කාලීන කරයි.
දැන් ඔබට පරිශීලකයාගෙන් ප්‍රමාදයන් සඟවා ඔබට අවශ්ය පරිදි ගොඩනැගීමේ කාලය වැඩි කර ධාරිතාව අවහිර කළ හැකිය.
වෙනත් මෙවලම්
දාම කේතය ගැන මෙහි කිසිවක් කීවේ නැත, මන්ද සාමාන්‍යයෙන් එහි ප්රශස්ත කිරීමට කිසිවක් නොමැති බැවිනි. දාම කේතය හැකි තරම් සරල සහ ආරක්ෂිත විය යුතුය - එයට අවශ්ය වන්නේ එපමණයි. සරලව සහ ආරක්ෂිතව chaincode ලිවීමට රාමුව අපට බොහෝ උපකාර කරයි. S7 Techlab සහ ස්ථිතික විශ්ලේෂකය වෙතින් .
ඊට අමතරව, අපගේ කණ්ඩායම Fabric සමඟ වැඩ කිරීම සරල සහ විනෝදජනක කිරීමට උපයෝගිතා කට්ටලයක් සංවර්ධනය කරමින් සිටී: , සඳහා උපයෝගීතාව (සංවිධාන එකතු කිරීම/ඉවත් කිරීම, RAFT නෝඩ්), සඳහා උපයෝගීතාව . ඔබ දායක වීමට කැමති නම්, සාදරයෙන් පිළිගනිමු.
නිගමනය
මෙම ප්‍රවේශය මගින් Hyperledger Fabric වෙනුවට Quorum, වෙනත් පුද්ගලික Ethereum ජාල (PoA හෝ PoW) ප්‍රතිස්ථාපනය කිරීම පහසු කරයි, සැබෑ ප්‍රතිදානය සැලකිය යුතු ලෙස අඩු කරයි, නමුත් ඒ සමඟම සාමාන්ය UX (බ්‍රවුසරයේ පරිශීලකයින් සඳහා සහ ඒකාබද්ධ පද්ධති පැත්තෙන් යන දෙකම පවත්වා ගනී. ) යෝජනා ක්‍රමය තුළ Fabric Ethereum සමඟ ප්‍රතිස්ථාපනය කරන විට, MVCC ගැටුම් හැසිරවීමේ සිට පරමාණුක නොවන වර්ධකයකට සහ නැවත යැවීමට නැවත උත්සාහ කිරීමේ සේවාවේ / සැරසිලි කරුගේ තර්කය පමණක් වෙනස් කිරීමට අවශ්ය වනු ඇත. බෆරින් කිරීම සහ තත්ව ආචයනය මඟින් ප්‍රතිචාර කාලය බ්ලොක් සෑදීමේ වේලාවෙන් විසංයෝජනය කිරීමට හැකි විය. දැන් ඔබට ඇණවුම් නෝඩ් දහස් ගණනක් එකතු කළ හැකි අතර බ්ලොක් බොහෝ විට සෑදී ඇණවුම් කිරීමේ සේවාව පූරණය කිරීමට බිය නොවන්න.
පොදුවේ, මට බෙදා ගැනීමට අවශ්ය වූයේ මෙයයි. එය යමෙකුගේ කාර්යයට උදව් කරන්නේ නම් මම සතුටු වෙමි.
මූලාශ්රය: www.habr.com