ਨਹੀਂ, ਬਲਾਕਚੈਨ 'ਤੇ ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨ (dapp) ਨੂੰ ਲਾਂਚ ਕਰਨ ਨਾਲ ਸਫਲ ਕਾਰੋਬਾਰ ਨਹੀਂ ਹੋਵੇਗਾ। ਵਾਸਤਵ ਵਿੱਚ, ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾ ਇਸ ਬਾਰੇ ਵੀ ਨਹੀਂ ਸੋਚਦੇ ਕਿ ਕੀ ਐਪਲੀਕੇਸ਼ਨ ਬਲਾਕਚੈਨ 'ਤੇ ਚੱਲਦੀ ਹੈ - ਉਹ ਸਿਰਫ਼ ਇੱਕ ਉਤਪਾਦ ਚੁਣਦੇ ਹਨ ਜੋ ਸਸਤਾ, ਤੇਜ਼ ਅਤੇ ਸਰਲ ਹੋਵੇ।

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਭਾਵੇਂ ਬਲਾਕਚੈਨ ਦੀਆਂ ਆਪਣੀਆਂ ਵਿਲੱਖਣ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਲਾਭ ਹਨ, ਇਸ 'ਤੇ ਚੱਲਣ ਵਾਲੀਆਂ ਜ਼ਿਆਦਾਤਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਉਨ੍ਹਾਂ ਦੇ ਕੇਂਦਰੀਕ੍ਰਿਤ ਪ੍ਰਤੀਯੋਗੀਆਂ ਨਾਲੋਂ ਬਹੁਤ ਮਹਿੰਗੀਆਂ, ਹੌਲੀ ਅਤੇ ਘੱਟ ਅਨੁਭਵੀ ਹੁੰਦੀਆਂ ਹਨ।

ਬਲਾਕਚੈਨ 'ਤੇ ਬਣਾਏ ਗਏ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਵ੍ਹਾਈਟਪੇਪਰਾਂ ਵਿੱਚ ਅਕਸਰ, ਤੁਸੀਂ ਇੱਕ ਪੈਰਾ ਲੱਭ ਸਕਦੇ ਹੋ ਜੋ ਕਹਿੰਦਾ ਹੈ: "ਬਲਾਕਚੈਨ ਮਹਿੰਗਾ ਹੈ ਅਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੈਣ-ਦੇਣ ਦੀ ਲੋੜੀਂਦੀ ਗਿਣਤੀ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਬਹੁਤ ਸਾਰੇ ਸਮਾਰਟ ਲੋਕ ਬਲਾਕਚੈਨ ਨੂੰ ਸਕੇਲ ਕਰਨ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਜਦੋਂ ਤੱਕ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਲਾਂਚ ਹੁੰਦੀ ਹੈ, ਇਹ ਕਾਫ਼ੀ ਮਾਪਯੋਗ ਬਣ ਜਾਵੇਗਾ।"

ਇੱਕ ਸਧਾਰਨ ਪੈਰੇ ਵਿੱਚ, ਇੱਕ ਡੈਪ ਡਿਵੈਲਪਰ ਸਕੇਲੇਬਿਲਟੀ ਮੁੱਦਿਆਂ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਦੇ ਵਿਕਲਪਕ ਹੱਲਾਂ ਦੀ ਡੂੰਘੀ ਚਰਚਾ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ। ਇਹ ਅਕਸਰ ਇੱਕ ਅਕੁਸ਼ਲ ਆਰਕੀਟੈਕਚਰ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਬਲਾਕਚੈਨ 'ਤੇ ਚੱਲ ਰਹੇ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਬੈਕਐਂਡ ਅਤੇ ਕੋਰ ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹਨ।

ਹਾਲਾਂਕਿ, ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ ਲਈ ਅਜੇ ਵੀ ਅਣਪਛਾਤੇ ਪਹੁੰਚ ਹਨ ਜੋ ਬਲਾਕਚੈਨ 'ਤੇ ਨਿਰਭਰਤਾ ਨੂੰ ਘਟਾ ਕੇ ਬਹੁਤ ਵਧੀਆ ਮਾਪਯੋਗਤਾ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਬਲਾਕਸਟੈਕ ਇੱਕ ਆਰਕੀਟੈਕਚਰ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਅਤੇ ਤਰਕ ਨੂੰ ਆਫ-ਚੇਨ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਆਉ ਪਹਿਲਾਂ ਇੱਕ ਹੋਰ ਪਰੰਪਰਾਗਤ ਪਹੁੰਚ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ, ਜੋ ਕਿ ਬਲਾਕਚੈਨ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾਵਾਂ ਵਿਚਕਾਰ ਇੱਕ ਸਿੱਧੇ ਵਿਚੋਲੇ ਵਜੋਂ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਜੋ ਖਾਸ ਤੌਰ 'ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮਾਪਦਾ ਨਹੀਂ ਹੈ।

ਪਹੁੰਚ #1: ਬੈਕਐਂਡ ਵਜੋਂ ਬਲਾਕਚੈਨ

ਚੀਜ਼ਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ, ਆਓ ਹੋਟਲ ਉਦਯੋਗ ਨੂੰ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਲੈਂਦੇ ਹਾਂ। ਇਹ ਇਕ ਬਹੁਤ ਵੱਡਾ ਉਦਯੋਗ ਹੈ ਜਿਸ ਵਿਚ ਵਿਚੋਲੇ ਜਿਵੇਂ Booking.com, ਉਹ ਇੱਕ ਵੱਡੀ ਫੀਸ ਲੈਂਦੇ ਹਨ ਮਹਿਮਾਨਾਂ ਅਤੇ ਹੋਟਲਾਂ ਨੂੰ ਜੋੜਨ ਲਈ।

ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਜਿੱਥੇ ਅਸੀਂ ਇਸ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਅਜਿਹੇ ਵਿਚੋਲੇ ਨੂੰ ਹਰਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਅਸੀਂ ਬਲਾਕਚੈਨ ਜਿਵੇਂ ਕਿ ਈਥਰਿਅਮ 'ਤੇ ਸਮਾਰਟ ਕੰਟਰੈਕਟਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਦੇ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਦੁਹਰਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ।

"ਵਿਸ਼ਵ ਕੰਪਿਊਟਰ" 'ਤੇ ਚੱਲ ਰਹੇ ਓਪਨ ਸੋਰਸ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਵਪਾਰੀਆਂ ਨੂੰ ਕਿਸੇ ਤੀਜੀ ਧਿਰ ਤੋਂ ਬਿਨਾਂ ਖਪਤਕਾਰਾਂ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹਨ, ਅੰਤ ਵਿੱਚ ਵਿਚੋਲੇ ਦੁਆਰਾ ਚਾਰਜ ਕੀਤੀਆਂ ਗਈਆਂ ਫੀਸਾਂ ਅਤੇ ਕਮਿਸ਼ਨਾਂ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ।

ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਦਿੱਤੀ ਤਸਵੀਰ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ, ਹੋਟਲ ਕਮਰਿਆਂ ਬਾਰੇ ਬਲਾਕਚੈਨ ਜਾਣਕਾਰੀ, ਹਫ਼ਤੇ ਦੇ ਦਿਨਾਂ ਜਾਂ ਵੀਕਐਂਡ 'ਤੇ ਉਹਨਾਂ ਦੀ ਉਪਲਬਧਤਾ ਅਤੇ ਕੀਮਤਾਂ, ਅਤੇ ਸ਼ਾਇਦ ਹੋਰ ਸਾਰੀਆਂ ਸੰਬੰਧਿਤ ਜਾਣਕਾਰੀ ਵਾਲੇ ਕਮਰਿਆਂ ਦਾ ਵੇਰਵਾ ਪੋਸਟ ਕਰਨ ਲਈ ਇੱਕ ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

ਕੋਈ ਵੀ ਜੋ ਕਮਰਾ ਬੁੱਕ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਉਹ ਬਲਾਕਚੈਨ 'ਤੇ ਹੋਸਟ ਕੀਤੇ ਹੋਟਲਾਂ ਅਤੇ ਕਮਰਿਆਂ ਦੀ ਖੋਜ ਕਰਨ ਲਈ ਇਸ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਉਪਭੋਗਤਾ ਇੱਕ ਕਮਰਾ ਚੁਣ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਰਿਜ਼ਰਵੇਸ਼ਨ ਇੱਕ ਡਿਪਾਜ਼ਿਟ ਵਜੋਂ ਹੋਟਲ ਨੂੰ ਲੋੜੀਂਦੀ ਮਾਤਰਾ ਵਿੱਚ ਟੋਕਨ ਭੇਜ ਕੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਅਤੇ ਜਵਾਬ ਵਿੱਚ, ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਬਲਾਕਚੈਨ ਵਿੱਚ ਜਾਣਕਾਰੀ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਕਿ ਨੰਬਰ ਹੁਣ ਉਪਲਬਧ ਨਹੀਂ ਹੈ।

ਇਸ ਪਹੁੰਚ ਨਾਲ ਸਕੇਲੇਬਿਲਟੀ ਸਮੱਸਿਆ ਦੇ ਦੋ ਪਾਸੇ ਹਨ। ਪਹਿਲਾਂ, ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੈਣ-ਦੇਣ ਦੀ ਅਧਿਕਤਮ ਸੰਖਿਆ। ਦੂਜਾ, ਬਲਾਕਚੈਨ 'ਤੇ ਸਟੋਰ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਡੇਟਾ ਦੀ ਮਾਤਰਾ।

ਆਓ ਕੁਝ ਮੋਟੇ ਗਣਨਾ ਕਰੀਏ। Booking.com ਦਾ ਕਹਿਣਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਕੋਲ ਲਗਭਗ 2 ਮਿਲੀਅਨ ਹੋਟਲ ਰਜਿਸਟਰਡ ਹਨ। ਮੰਨ ਲਓ ਕਿ ਔਸਤ ਹੋਟਲ ਵਿੱਚ 10 ਕਮਰੇ ਹਨ ਅਤੇ ਹਰ ਇੱਕ ਸਾਲ ਵਿੱਚ ਸਿਰਫ਼ 20 ਵਾਰ ਬੁੱਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਜਿਸ ਨਾਲ ਸਾਨੂੰ ਪ੍ਰਤੀ ਸਕਿੰਟ ਔਸਤਨ 13 ਬੁਕਿੰਗ ਮਿਲਦੀ ਹੈ।

ਇਸ ਨੰਬਰ ਨੂੰ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਿੱਚ ਪਾਉਣ ਲਈ, ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ Ethereum ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 15 ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦਾ ਹੈ.

ਇਸਦੇ ਨਾਲ ਹੀ, ਇਹ ਵਿਚਾਰਨ ਯੋਗ ਹੈ ਕਿ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਹੋਟਲਾਂ ਤੋਂ ਲੈਣ-ਦੇਣ ਵੀ ਸ਼ਾਮਲ ਹੋਣਗੇ - ਉਹਨਾਂ ਦੇ ਕਮਰਿਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਅਤੇ ਲਗਾਤਾਰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ। ਹੋਟਲ ਕਮਰੇ ਦੀਆਂ ਕੀਮਤਾਂ ਨੂੰ ਅਕਸਰ ਅਪਡੇਟ ਕਰਦੇ ਹਨ, ਕਈ ਵਾਰ ਰੋਜ਼ਾਨਾ ਵੀ, ਅਤੇ ਹਰੇਕ ਕੀਮਤ ਜਾਂ ਵਰਣਨ ਵਿੱਚ ਤਬਦੀਲੀ ਲਈ ਬਲਾਕਚੈਨ 'ਤੇ ਇੱਕ ਲੈਣ-ਦੇਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇੱਥੇ ਆਕਾਰ ਦੇ ਮੁੱਦੇ ਵੀ ਹਨ - Ethereum blockchain ਦਾ ਭਾਰ ਹਾਲ ਹੀ ਵਿੱਚ 2TB ਮਾਰਕ ਨੂੰ ਪਾਸ ਕੀਤਾ ਹੈ. ਜੇਕਰ ਇਸ ਪਹੁੰਚ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਸੱਚਮੁੱਚ ਪ੍ਰਸਿੱਧ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ Ethereum ਨੈੱਟਵਰਕ ਬਹੁਤ ਅਸਥਿਰ ਹੋ ਜਾਵੇਗਾ।

ਅਜਿਹੀ ਬਲਾਕਚੈਨ-ਅਧਾਰਿਤ ਪ੍ਰਣਾਲੀ ਇਸਦੀ ਨਿਰਪੱਖਤਾ ਅਤੇ ਕੇਂਦਰੀਕਰਨ ਦੀ ਘਾਟ ਕਾਰਨ ਬਾਹਰਲੇ ਲੋਕਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢ ਸਕਦੀ ਹੈ, ਬਲਾਕਚੈਨ ਤਕਨਾਲੋਜੀ ਦੇ ਮੁੱਖ ਫਾਇਦੇ। ਪਰ ਬਲਾਕਚੈਨ ਦੀਆਂ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵੀ ਹਨ - ਇਹ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਿਆ ਜਾਂਦਾ, ਇਹ ਸ਼ਾਨਦਾਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਲੈਣ-ਦੇਣ ਦੀ ਗਤੀ ਅਤੇ ਕਮਿਸ਼ਨ ਵਿੱਚ ਉਹਨਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਇਸ ਲਈ, ਡੈਪ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਬਲਾਕਚੈਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੀ ਹਰੇਕ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਅਸਲ ਵਿੱਚ ਵੰਡ ਅਤੇ ਗੈਰ-ਲਿਖਣਯੋਗਤਾ ਦੀ ਲੋੜ ਹੈ।

ਉਦਾਹਰਨ ਲਈ: ਹਰ ਹੋਟਲ ਦੇ ਡੇਟਾ ਨੂੰ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਸੈਂਕੜੇ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਵੰਡਣ ਅਤੇ ਇਸਨੂੰ ਸਥਾਈ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰਨ ਦਾ ਕੀ ਫਾਇਦਾ ਹੈ? ਕੀ ਇਹ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਕਮਰੇ ਦੀਆਂ ਦਰਾਂ ਅਤੇ ਉਪਲਬਧਤਾ ਬਾਰੇ ਇਤਿਹਾਸਕ ਡੇਟਾ ਹਮੇਸ਼ਾ ਬਲਾਕਚੈਨ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ? ਸ਼ਾਇਦ ਨਹੀਂ।

ਜੇਕਰ ਅਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਸਵਾਲ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਇਹ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵਾਂਗੇ ਕਿ ਸਾਨੂੰ ਸਾਡੇ ਸਾਰੇ ਫੰਕਸ਼ਨਾਂ ਲਈ ਸਾਰੀਆਂ ਮਹਿੰਗੀਆਂ ਬਲਾਕਚੈਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਵਿਕਲਪ ਕੀ ਹੈ?

ਪਹੁੰਚ #2: ਬਲਾਕਸਟੈਕ ਪ੍ਰੇਰਿਤ ਆਰਕੀਟੈਕਚਰ

ਹਾਲਾਂਕਿ ਮੁੱਖ ਜ਼ੋਰ ਬਲਾਕ ਸਟੈਕ ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ 'ਤੇ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਉਪਭੋਗਤਾ ਆਪਣੇ ਡੇਟਾ ਦੇ ਮਾਲਕ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਜਿਵੇਂ ਕਿ ਏਅਰਟੈਕਸਟ, BentenSound, ਚਿੱਤਰ ਆਪਟੀਮਾਈਜ਼ਰ ਜ ਗ੍ਰੈਫਾਈਟ), ਬਲਾਕਸਟੈਕ ਵਿੱਚ ਬਲਾਕਚੈਨ ਨੂੰ ਹਲਕੇ ਤੌਰ 'ਤੇ ਵਰਤਣ ਦਾ ਇੱਕ ਫਲਸਫਾ ਵੀ ਹੈ-ਸਿਰਫ ਜਦੋਂ ਬਿਲਕੁਲ ਜ਼ਰੂਰੀ ਹੋਵੇ। ਉਹਨਾਂ ਦੀ ਮੁੱਖ ਦਲੀਲ ਇਹ ਹੈ ਕਿ ਬਲਾਕਚੈਨ ਹੌਲੀ ਅਤੇ ਮਹਿੰਗਾ ਹੈ, ਅਤੇ ਇਸਲਈ ਇਸਦੀ ਵਰਤੋਂ ਸਿਰਫ ਸਿੰਗਲ ਜਾਂ ਕਦੇ-ਕਦਾਈਂ ਲੈਣ-ਦੇਣ ਲਈ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਨਾਲ ਬਾਕੀ ਦੀ ਗੱਲਬਾਤ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਦੁਆਰਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਯਾਨੀ. ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਬਲੌਕਚੇਨ ਦੀ ਬਜਾਏ ਇੱਕ ਦੂਜੇ ਨਾਲ ਸਿੱਧਾ ਡੇਟਾ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਆਖ਼ਰਕਾਰ, ਸਭ ਤੋਂ ਪੁਰਾਣੀਆਂ ਅਤੇ ਸਭ ਤੋਂ ਸਫਲ ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਜਿਵੇਂ ਕਿ ਬਿਟਟੋਰੈਂਟ, ਈਮੇਲ ਅਤੇ ਟੋਰ ਬਲਾਕਚੈਨ ਦੀ ਧਾਰਨਾ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਬਣਾਏ ਗਏ ਸਨ।

ਖੱਬੇ: ਪਹਿਲੀ ਪਹੁੰਚ, ਜਿਸ ਵਿੱਚ ਉਪਭੋਗਤਾ ਬਲਾਕਚੈਨ ਰਾਹੀਂ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ। ਸੱਜਾ: ਉਪਭੋਗਤਾ ਇੱਕ ਦੂਜੇ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਬਲਾਕਚੈਨ ਸਿਰਫ ਪਛਾਣ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ.

ਆਉ ਹੋਟਲ ਬੁਕਿੰਗ ਉਦਾਹਰਨ ਤੇ ਵਾਪਸ ਚਲੀਏ. ਅਸੀਂ ਮਹਿਮਾਨਾਂ ਨੂੰ ਹੋਟਲਾਂ ਨਾਲ ਜੋੜਨ ਲਈ ਇੱਕ ਨਿਰਪੱਖ, ਸੁਤੰਤਰ ਅਤੇ ਖੁੱਲ੍ਹਾ ਪ੍ਰੋਟੋਕੋਲ ਚਾਹੁੰਦੇ ਹਾਂ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਅਸੀਂ ਕੇਂਦਰੀਕ੍ਰਿਤ ਵਿਚੋਲੇ ਨੂੰ ਹਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਸਾਨੂੰ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਾਂਝੇ ਵੰਡੇ ਬਹੀ ਵਿੱਚ ਕਮਰੇ ਦੀਆਂ ਕੀਮਤਾਂ ਨੂੰ ਲਗਾਤਾਰ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਅਸੀਂ ਮਹਿਮਾਨਾਂ ਅਤੇ ਹੋਟਲਾਂ ਨੂੰ ਬਲਾਕਚੈਨ ਰਾਹੀਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਗੱਲਬਾਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਕਿਉਂ ਨਹੀਂ ਦਿੰਦੇ ਹਾਂ। ਹੋਟਲ ਆਪਣੀਆਂ ਕੀਮਤਾਂ, ਕਮਰੇ ਦੀ ਉਪਲਬਧਤਾ ਅਤੇ ਕੋਈ ਹੋਰ ਜਾਣਕਾਰੀ ਕਿਤੇ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹਨ ਜਿੱਥੇ ਇਹ ਹਰ ਕਿਸੇ ਲਈ ਪਹੁੰਚਯੋਗ ਹੋਵੇਗੀ - ਉਦਾਹਰਨ ਲਈ, IPFS, Amazon S3, ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਉਹਨਾਂ ਦਾ ਆਪਣਾ ਸਥਾਨਕ ਸਰਵਰ। ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜਿਸਨੂੰ ਬਲਾਕਸਟੈਕ ਦੀ ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਸਟੋਰੇਜ ਪ੍ਰਣਾਲੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਗੇਆ. ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇਹ ਚੁਣਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਕਿ ਉਹ ਆਪਣਾ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ ਅਤੇ ਨਿਯੰਤਰਣ ਕਰਦੇ ਹਨ ਕਿ ਨਾਮਕ ਪਹੁੰਚ ਦੁਆਰਾ ਕੌਣ ਇਸ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ ਬਹੁ-ਉਪਭੋਗਤਾ ਸਟੋਰੇਜ਼.

ਭਰੋਸਾ ਸਥਾਪਤ ਕਰਨ ਲਈ, ਹੋਟਲ ਦੇ ਸਾਰੇ ਡੇਟਾ ਨੂੰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ 'ਤੇ ਹੋਟਲ ਦੁਆਰਾ ਦਸਤਖਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਭਾਵੇਂ ਇਹ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਸਦੀ ਇਕਸਾਰਤਾ ਨੂੰ ਬਲਾਕਚੈਨ 'ਤੇ ਸਟੋਰ ਕੀਤੇ ਹੋਟਲ ਦੀ ਪਛਾਣ ਨਾਲ ਜੁੜੀਆਂ ਜਨਤਕ ਕੁੰਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਬਲਾਕਸਟੈਕ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਬਲਾਕਚੈਨ 'ਤੇ ਸਿਰਫ਼ ਤੁਹਾਡੀ ਪਛਾਣ ਦੀ ਜਾਣਕਾਰੀ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਹਰੇਕ ਉਪਭੋਗਤਾ ਦੇ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਜ਼ੋਨ ਫਾਈਲਾਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਨੋਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਨੈਟਵਰਕ ਦੁਆਰਾ ਵੰਡੀ ਜਾਂਦੀ ਹੈ। ਅਤੇ ਇੱਕ ਵਾਰ ਫਿਰ, ਤੁਹਾਨੂੰ ਨੋਡ ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ ਡੇਟਾ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਬਲਾਕਚੈਨ ਅਤੇ ਹੋਰ ਉਪਭੋਗਤਾਵਾਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਹੈਸ਼ਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰਕੇ ਇਸਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ।

ਸਿਸਟਮ ਦੇ ਇੱਕ ਸਰਲ ਰੂਪ ਵਿੱਚ, ਮਹਿਮਾਨ ਹੋਟਲਾਂ ਦੀ ਖੋਜ ਕਰਨ ਅਤੇ ਆਪਣੇ ਕਮਰਿਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਬਲਾਕਸਟੈਕ ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਨੈੱਟਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਨਗੇ। ਅਤੇ ਤੁਹਾਡੇ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਸਾਰੇ ਡੇਟਾ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਇਕਸਾਰਤਾ ਨੂੰ ਜਨਤਕ ਕੁੰਜੀਆਂ ਅਤੇ ਹੈਸ਼ਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਵਰਚੁਅਲ ਸਰਕਟ ਬਲਾਕਸਟੈਕ।

ਇਹ ਆਰਕੀਟੈਕਚਰ ਪਹਿਲੀ ਪਹੁੰਚ ਨਾਲੋਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੈ ਅਤੇ ਇਸ ਲਈ ਵਧੇਰੇ ਵਿਆਪਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਬਿਲਕੁਲ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਬਲਾਕਸਟੈਕ ਆਉਂਦਾ ਹੈ, ਅਜਿਹੇ ਵਿਕੇਂਦਰੀਕਰਣ ਪ੍ਰਣਾਲੀ ਨੂੰ ਬਣਾਉਣ ਲਈ ਸਾਰੇ ਲੋੜੀਂਦੇ ਹਿੱਸੇ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਇਸ ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਾਲ, ਅਸੀਂ ਸਿਰਫ਼ ਬਲਾਕਚੈਨ 'ਤੇ ਡਾਟਾ ਸਟੋਰ ਕਰਦੇ ਹਾਂ ਜਿਸ ਨੂੰ ਅਸਲ ਵਿੱਚ ਵੰਡਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਓਵਰਰਾਈਟ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਬਲਾਕਸਟੈਕ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਰਜਿਸਟਰ ਕਰਨ ਅਤੇ ਇਹ ਦਰਸਾਉਣ ਲਈ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਸਿਰਫ ਬਲਾਕਚੈਨ 'ਤੇ ਲੈਣ-ਦੇਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਜਾਣਕਾਰੀ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਹੋਰ ਲੈਣ-ਦੇਣ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਆਵਰਤੀ ਘਟਨਾ ਨਹੀਂ ਹੈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਐਪਲੀਕੇਸ਼ਨ ਤਰਕ, ਪਹਿਲੀ ਪਹੁੰਚ ਦੇ ਉਲਟ, ਕਲਾਇੰਟ ਸਾਈਡ 'ਤੇ ਚੱਲਦਾ ਹੈ ਨਾ ਕਿ ਸਮਾਰਟ ਕੰਟਰੈਕਟਸ' ਤੇ. ਇਹ ਡਿਵੈਲਪਰ ਨੂੰ ਇਸ ਤਰਕ ਨੂੰ ਮਹਿੰਗੇ ਜਾਂ ਕਈ ਵਾਰ ਅਸੰਭਵ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਅੱਪਡੇਟ ਤੋਂ ਬਿਨਾਂ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਅਤੇ ਤਰਕ ਨੂੰ ਆਫ-ਚੇਨ ਰੱਖ ਕੇ, ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨ ਰਵਾਇਤੀ ਕੇਂਦਰੀਕ੍ਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਮਾਪਯੋਗਤਾ ਦੇ ਪੱਧਰਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਸਿੱਟਾ

ਬਲਾਕਸਟੈਕ 'ਤੇ ਚੱਲ ਰਹੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਰਵਾਇਤੀ ਬਲਾਕਚੈਨ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨਾਲੋਂ ਬਹੁਤ ਵਧੀਆ ਢੰਗ ਨਾਲ ਸਕੇਲ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਆਪਣੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਜਵਾਬ ਨਾ ਦਿੱਤੇ ਸਵਾਲਾਂ ਦੇ ਨਾਲ ਇੱਕ ਛੋਟੀ ਪਹੁੰਚ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਇੱਕ ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨ ਸਮਾਰਟ ਕੰਟਰੈਕਟ 'ਤੇ ਨਹੀਂ ਚੱਲਦੀ ਹੈ, ਤਾਂ ਇਹ ਉਪਯੋਗਤਾ ਟੋਕਨਾਂ ਦੀ ਲੋੜ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। ਇਸ ਨਾਲ ਕਾਰੋਬਾਰਾਂ ਲਈ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋ ਸਕਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ICO ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ (ਬਲਾਕਸਟੈਕ ਸਮੇਤ) ਲਈ ਫੰਡਿੰਗ ਦਾ ਮੁੱਖ ਸਰੋਤ ਰਹੇ ਹਨ।

ਇੱਥੇ ਤਕਨੀਕੀ ਸਮੱਸਿਆਵਾਂ ਵੀ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਵਿੱਚ ਇੱਕ ਹੋਟਲ ਬੁਕਿੰਗ ਫੰਕਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਮੁਕਾਬਲਤਨ ਆਸਾਨ ਹੈ, ਜਿੱਥੇ ਇੱਕ ਪ੍ਰਮਾਣੂ ਕਾਰਵਾਈ ਵਿੱਚ, ਟੋਕਨਾਂ ਦੇ ਬਦਲੇ ਕਮਰੇ ਰਿਜ਼ਰਵੇਸ਼ਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਅਤੇ ਇਹ ਬਹੁਤ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਸਮਾਰਟ ਕੰਟਰੈਕਟ ਦੇ ਬਿਨਾਂ ਬਲਾਕਸਟੈਕ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਬੁਕਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰੇਗੀ।

ਐਪਸ ਜੋ ਲੱਖਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੰਭਾਵਨਾ ਦੇ ਨਾਲ ਗਲੋਬਲ ਬਾਜ਼ਾਰਾਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਸਫਲ ਹੋਣ ਲਈ ਬਹੁਤ ਵਧੀਆ ਢੰਗ ਨਾਲ ਸਕੇਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ ਸਕੇਲੇਬਿਲਟੀ ਦੇ ਇਸ ਪੱਧਰ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਿਰਫ਼ ਬਲਾਕਚੈਨ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਇੱਕ ਗਲਤੀ ਹੈ। ਬੁਕਿੰਗ ਡਾਟ ਕਾਮ ਵਰਗੇ ਵੱਡੇ ਕੇਂਦਰੀਕ੍ਰਿਤ ਬਾਜ਼ਾਰ ਦੇ ਖਿਡਾਰੀਆਂ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ, ਵਿਕੇਂਦਰੀਕ੍ਰਿਤ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਉਹਨਾਂ ਦੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਲਈ ਵਿਕਲਪਿਕ ਪਹੁੰਚਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਬਲਾਕਸਟੈਕ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਇੱਕ।

ਸਰੋਤ: www.habr.com