The Urdu Version of Steem Whitepaper - Page 20 to 22 containing +1350 translated words - 68% Translation is Completed!

Welcome to the Urdu version of Steem Whitepaper (in progress). I'm glad to say that I am able to translate the whitepaper in good speed. At this point, the total progress is 68%. That means only 32% translation is remaining to the complete translation of Steem Whitepaper. You can assume how hard I've been working to translate the paper as quickly as possible. This post contains over 1350 translated words, taking the progress from 60% to 68%.

I am excited to welcome the Urdu community in Steemit and it excites me even more when I read that you're also ready to welcome the Urdu community. It will be a fun to grow Steemit globally.

Image Credits: BielCorp

The following is the table of contents for this post:

• Fees are a Barrier to Entry
• Changing Fees
• Sybil Attacks
• Full Reserve vs Fractional Reserve
• Bandwidth Instead of Micropayment Channels
• Impact of Capacity
• Comparison to Fees
• Account Creation

:فیس اندراج میں رکاوٹ ہیں

کوئی بھی فیس نئے صارفین کے اندراج میں رکاوٹ پیدا کرتی ہیں۔ اس سے پہلے کہ کوئی ایتھریم کو استعمال کر کے تجربہ کر سکے، انہیں کچھ ای-ٹی-ایچ ٹوکن حاصل کرنا لازمی ہے۔ کوئی بھی شخص جو ایتھریم کے بلاکچین پر غیرمرکزی ایپلیکیشن بنانا چاہتا ہے، انہیں اپنے گاہکوں تک پہنچنے کے لیے خرچے سے گزرنا لازمی ہے۔ کرائیپٹوکرنسی کو خریدنا ایک آسان کام نہیں اور دس ڈالر سے کم کی خرید بہت کم ہی سمجھ آتی ہے۔ اس کا یہ مطلب کہ نئے صارفین جو نئی ایپلیکیشن کو استعمال کرنا چاہتے ہیں، ان کا کم سے کم دس ڈالر کے ساتھ حصہ لینے پر قائل ہونا لازمی ہے۔

Fees are a Barrier to Entry

Any fee creates a barrier to entry for new users. Before someone can experiment with Ethereum they must acquire some ETH tokens. Anyone wanting to build a decentralized application on Ethereum must pass on the cost to their customers. Buying a crypto currency is not an easy task and rarely makes sense for amounts less than $10. This means that new users wanting to try out a new decentralized application must first be convinced to part with $10.

:فیس میں تبدیلی

وقت کے ساتھ ایک نیٹ ورک فیس میں لازمی تبدیلی کرتا رہے۔ یا تو یہ ٹوکن کی قدروقیمت میں اضافے یا صلاحیت میں اضافے کی وجہ سے ہو سکتا ہے۔ صارفین متوقع فیس اور ضمانت شدہ خدمات کو پسند کرتے ہیں۔ اگرچہ بھاری استعمال کے اوقات میں فیس کو متحرک طور پر تبدیل کرنا ممکن ہے، نتیجہ صارف کا خراب تجربہ ہے۔

Changing Fees

Over time a network must adjust fees. This can happen either due to an increase in the value of the token or due to a surge in capacity. Users like predictable fees and guaranteed service. While it is possible to dynamically adjust fees during times of heavy use, the result is a poor user experience.

:سائبل حملے

مرکزی ویب سائٹس فضولیات کو شرح کے محدود کرنے اور کسی قسم کی شناخت کی تصدیق کے ذریعے روکتی ہیں۔ یہاں تک کہ کچھ سادہ سے سادہ جیسے ریکیپچا بھی جعلی اکاونٹس کی تخلیق کو محدود کرنے کے لئے کافی ہے۔ اگر کوئی ان کے اکاونٹ کا غلط استعمال کرتا ہے تو مرکزی ویب سائٹس ان اکاونٹ کو بند کرنے کی آزادی رکھتی ہیں۔

ایک غیرمرکزی نطام میں، صارفین کی پابندی کے لئے کوئی براہ راست راستہ نہیں ہے اور نہ ہی کوئی مرکزی خدمات دینے والا ریکیپچا کے ذریعے جعلی اکاونٹس کی شرح کو محدود کر سکتا ہے۔ حقیقت میں، صارفین کے احتساب کی صلاحیت کا نہ ہونا ہی بلاکچین ٹیکنالوجی کی فروخت کے مرکزی اشاروں میں سے ایک اہم اشارہ ہے۔

Sybil Attacks

Centralized websites prevent spam through rate limiting and some form of ID verification. Even something as simple as reCAPTCHA[^fn9] is sufficient to limit the creation of fake accounts. If someone abuses their account then centralized websites are free to block the account.

In a decentralized system there is no direct way to ban users nor centralized provider able to host a reCAPTCHA and enforce rate limiting of accounts. In fact, the inability to censor users is one of the main selling points of blockchain technology.

:کلی مختص بمقابل جزوی مختص

چلیں ایک بلاکچین کو ایک انٹرنیٹ سروس فراہم کرنے والی کمپنی کی طرح سمجھتے ہیں جو شہر کے تمام کیبلز کی مالک ہے اور اس کے پاس اتنا زیادہ بینڈوڈتھ ہے جو وہ کسی بھی وقت فراہم کر سکتی ہے۔ اس شہر کے رہنے والے لوگ اس کمپنی سے دستیاب بینڈوڈتھ کا کچھ حصہ خرید سکتے ہیں۔

انٹرنیٹ سروس فراہم کرنے والی کمپنی کے پاس ان دونوں میں سے ایک اتنخاب کرنے کا اختیار ہے: یا تو وہ کلی مختص نظام کا انتخاب کریں یا پھر جزوی مختص کا۔ کلی مختص نظام کے تحت ہر صارف کو زیادہ سے زیادہ بینڈوڈتھ کے کچھ حصے کے استعمال کی اجازت دی جاتی ہے جو صارف کے حصص کی خرید کے متناسب ہوتا ہے۔ کیونکہ ہر ایک صارف ایک ہی وقت میں انٹرنیٹ کا استعمال نہیں کرتے، اس لئے شہر کا نیٹ معنی خیز طور پر کم استعمال ہوگا۔

جزوی مختص نطام کے تحت انفرادی صارفین زیادہ بینڈوڈتھ کا استعمال کر سکتے ہیں بمقابل اس کے جس کے وہ ایک مخصوص وقت میں حقدار ہیں لیکن صرف اس وقت تک جب تک کہ ہر ایک صارف انٹرنیٹ کو ایک ہی وقت میں استعمال نہیں کرتا۔ جزوی مختص نظام چلانے میں مسئلہ یہ ہے کہ بھیڑ (رش) کسی بھی وقت لگ جاتی ہے جب بہت سے لوگ ایک ہی وقت میں انٹرنیٹ استعمال کرنا چاہتے ہیں۔ بھیڑ کے اوقات میں بینڈوڈتھ کی ترجیح کے لئے انٹرنیٹ سروس فراہم کرنے والے کو کسی راستے کی ضرورت ہے۔ بہت زیادہ انتہائی صورت میں، مکمل بھیڑ والا نیٹ ورک لازمی طور پر کلی مختص نظام کی طرف واپس لوٹتا ہے۔ مشکل کام ایک مناسب جزوی مختص کے تناسب کو قائم کرنا ہے۔

Full Reserve vs Fractional Reserve

Let’s view a blockchain like an Internet Service Provider (ISP) co-op which owns all of the cables in the town and has a maximum amount of bandwidth that it can provide at any time. People living in the town can buy shares in the ISP and in exchange they are entitled to utilize a portion of the available bandwidth.

The ISP has two choices, run a “full reserve” or “fractional reserve” system. Under a full reserve system each user is only allowed a fraction of the maximum bandwidth proportional to her shares. Because not everyone uses the Internet at the same time, the town’s network would be significantly underutilized.

Under a fractional reserve system the individual users could utilize more bandwidth than they are entitled to at any given point in time so long as not everyone uses the Internet at the same time. The problem with operating a fractional reserve is that congestion occurs anytime too many people wish to use the network at the same time. The ISP needs a way to prioritize bandwidth during congested periods. In the most extreme case, a fully congested network must revert to a full reserve system. The challenge is setting the proper fractional reserve ratio.

:چھوٹی ادائیگیوں کے تنگ راستے کے بجائے بینڈوڈتھ

چھوٹی ادائیگیوں کے مسائل کا حل متحرک جزوی مختص نظام کو لاگو کرنے میں ہے۔ اس نمونے کے تحت بلاکچین بھیڑ کے اوقات میں خودکار طریقے سے مختص کے تناسب کو ترتیب دیتا رہے گا۔ بلاکچین ایک ہدف کے استعمال کو قائم کرے گا جو قلیل مدتی طلب کے اضافے کے لئے کافی جگہ چھوڑے گا۔ کسی بھی وقت اگر یہ اضافہ برقرار رہے، بلاکچین زیادہ سے زیادہ بینڈوڈتھ فی حصہ کو کم کردیتا ہے۔ جب وہ بڑھتا ہوا اضافہ ختم ہو گیا ہو اور اضافی صلاحیت باقی ہو تو بلاکچین آہستہ آہستہ بینڈوڈتھ فی حصہ میں اضافہ کردیتا ہے۔

ایک انفرادی صارف کی طرف سے استعمال شدہ بینڈوڈتھ مناسب وقت کی حد تک ماپا جانا چاہئیے تاکہ صارف کو استعمال کے اوقات میں تبدیلی کی اجازت مل سکے۔ صارفین لاگن ہوتے ہیں، بہت سی چیزیں ایک وقت میں کرتے ہیں اور پھر لاگ آوٹ ہو جاتے ہیں۔ اسکا مطلب یہ کہ ان کے استعمال شدہ بینڈوڈتھ کو کم عرصے میں ماپا جائے تو وہ بمقابل زیادہ عرصے کے بہت زیادہ دکھے گا۔ اگر وقت کے دورانیے کو زیادہ دور تک کھینچا گیا تو مختص کا تناسب قلیل مدتی اضافے کے جواب میں تیزی سے ترتیب نہیں پا سکے گا۔ اگر وقت کا دورانیہ بہت کم ہو تو عام صارفین پر استعمال کے جھنڈ کا بہت زیادہ اثر پڑے گا۔

ہمارے اندازے میں صارفین کے اوسط ہفتہ وار استعمال کو ماپا جانا کافی ہے۔ ہر بار جب ایک صارف ایک ٹرانزیکشن کی تصدیق کرتا ہے، تو وہ ٹرانزیکشن ان کے انفرادی حرکت پذیری اوسط کا جز بن جاتی ہے۔ کسی بھی وقت جب ایک صارف کی حرکت پذیری کا اوسط موجودہ نیٹ ورک کی حد سے تجاوز کر جائے، ان کے لین دین میں تاخیر پیدا ہو جاتی ہے جب تک ان کا اوسط موجودہ حد سے نیچے نہیں آجاتا۔

Bandwidth Instead of Micropayment Channels

The solution to the problems with micropayments is in implementing dynamic fractional reserves. Under this model the blockchain will automatically adjust the reserve ratio for the network during times of congestion. The blockchain will set a target utilization that leaves enough headroom for short term surges in demand. Any time the surges are sustained the blockchain reduces the maximum bandwidth-per-share. When a surge is over and there is surplus capacity the blockchain can slowly increase the bandwidth-per-share.

Bandwidth used by an individual user should be measured over a suitably long period of time to allow that user to time-shift their usage. Users tend to login, do many things at once, then logout. This means that their bandwidth over a short period of time may appear much higher than if viewed over a longer period of time. If the time window is stretched too far then the reserve ratio will not adjust fast enough to respond to short-term surges, if the window is too short then clustering usage will have too big of an impact on normal users.

In our estimate it should be sufficient to measure the average weekly bandwidth usage of users. Every time a user signs a transaction, that transaction is factored into their own individual moving average. Any time a user’s moving average exceeds the current network limit their transaction is delayed until their average falls below the limit.

:گنجائش کا اثر

ضروری نہیں کہ بلاکچین کی گنجائش محدود ہے۔ یہ انٹرنیٹ کے بنیادی ڈھانچے کی تکنیکی صلاحیت کے اندر بٹکوائن بلاک کے حجم کو ١٠ایم-بی تک بڑھانے کے لئے اچھی ہے جو نتیجے میں کم از کم ضروری توازن (بیلنس) کو دس کے عنصر سے کم کردے گی۔ جبکہ بٹکوائن فی الحال ایک سیکنڈ میں تین ٹرانزیکشن کی صلاحیت رکھتا ہے، متبادل عملدرآمد فی سیکنڈ ہزار ٹرانزیکشن کی صلاحیت رکھتے ہیں۔

Impact of Capacity

Blockchain capacity isn’t necessarily capped. It is well within the technological capability of internet infrastructure to increase the Bitcoin block size to 10MB which in turn will reduce the minimum required balance by a factor of 10. While Bitcoin currently supports about 3 transactions per second, alternative implementations are capable of over 1000 transactions per second.

:فیس کا موازنہ

اگر ہم فرض کریں کہ ایک صارف جس کے پاس ٢٥ ڈالرز کی قدر کے متناسب بٹکوائن ہیں وہ ہفتہ میں ایک بار ٹرانزیکشن (لین دین) کرتا ہے اور ہر بار ٤ سینٹ فیس کے طور پر دیتا ہے تو وہ ایک سال میں فیس کے طور پر ٢ ڈالر ادا کرے گا۔ ایک صارف کو فیس کے نقصان کو مٹانے لئے٢٥ ڈالرز پر ٨ فیصد منافع کمانا پڑے گا۔ امکانات یہ ہیں کہ صارفین ویسے بھی اپنے پیسوں کو بلاکچین پر ہی رکھنا چاہتے ہیں (یعنی ہولڈ کرنا چاہتے ہیں) تو اس ٢٥ ڈالرز والے صارف نے فیس کی حکمت عملی کے بجائے محدود شرح کی حکمت عملی استعمال کر کے ایک سال کے عرصے میں ٢ ڈالرز کی بچت کی۔ صرف ١٧٥ ڈالرز کے ساتھ یہ صارفین ہر دن لین دین کر سکتے اور سالانہ ١٤ ڈالرز کی بچت کر سکتے۔

Comparison to Fees

If we assume a user with $25 dollars worth of BTC transacts once per week and pays a $0.04 cent fee each time then they would pay over $2.00 in fees per year. A user would have to earn a 8% rate of return on their $25 dollars just to break even with paying fees. Chances are that users were going to hold their money on the blockchain anyway, so this user with $25 worth of BTC just saved $2 over the course of a year by adopting a rate-limiting approach rather than a fee-based approach. With just $175 they could transact every single day and save $14 per year.

:اکاونٹ کی تخلیق

عوامی طور پر جانے ہوئے توازن (بیلنس) کے ساتھ سٹیم کا اکاؤنٹ پر مبنی نظام بینڈوڈتھ پر مبنی محدود شرح کے الگورتھم کے نفاذ کو آسان بناتا ہے۔ کوئی بھی اکاونٹ جس کا توازن (بیلنس) کم سے کم لازمی بیلنس سے کم ہو، وہ ٹرانزیکشن نہیں کر پائے گا۔ اس کا مطلب یہ ہے کہ تمام نئے اکاونٹ کم سے کم اس ضروری بیلنس سے بھرپور ہونے چاہئیں۔ اس کا یہ بھی مطلب ہے کہ وہ صارفین جو چھوٹی ادائیگیوں کی لین دین کرنا چاہتے ہیں،جب تک ان کے اکاونٹ میں بڑا بیلنس موجود ہے وہ اس اکاونٹ کو دوبارہ بھی استعمال کر سکتے ہیں۔

کم بیلنس سے بھرے ہوئے اکاونٹ جسے قلیل استعمال کے وقت تخلیق کیا گیا تھا، اس کے لئے یہ ممکن ہے کہ جب نیٹ ورک پر بوجھ بڑھے تو وہ اکاونٹ ناقابل پہنچ ہو جائے۔ عارضی طور پر اکاؤنٹ میں بڑے توازن کو سونپ کر سرمائے کو کسی بھی وقت دوبارہ حاصل کیا جا سکتا ہے۔

لٹکے ہوئے اکاونٹ کی کم سے کم تعداد کے ساتھ صارف کے مناسب تجربے کو برقرار رکھنے کے لئے، تمام نئے اکاونٹ کو ہفتہ وار لین دین کے لئے درکار ضروری کم سے کم بیلنس سے ١٠ گناہ زیادہ بیلنس رکھنا ہوگا۔ اسطرح اگر طلب میں ١٠ گناہ اضافہ بھی ہو جائے تو اکاونٹ قابل پہنچ رہے گا۔

سائبل حملوں کے امکانات کی وجہ سے کوئی بھی ابتدائی اکاونٹ توازن (بیلنس) صارف کے پاس سے آنا ہوگا نہ کہ ٹوکن کی تخلیق سے۔

Account Creation

Steem’s account-based system with publicly known balances simplifies the implementation of the bandwidth-based rate limiting algorithm. Any account with a balance below the minimum required to transact once per week would be unable to transact. This implies that all new accounts should be funded with at least this minimum balance. It also implies that users wishing to transact in smaller amounts can, so long as they hold a larger balance and reuse the account.

It is possible for a low-balance account created during a time of low usage to become inaccessible if the network usage picks up. The funds could be recovered at any time by temporarily delegating a larger balance to the account.

In order to maintain a reasonable user experience with a minimum number of hung accounts, all new accounts should start out with a balance 10 times the minimum required to transact weekly. This way even if demand increases by a factor of 10 the account will remain viable.

Any initial account balance would have to come from the user creating the account and not from token creation due to the potential for sybil attacks.

Proof of Work (For Utopian):

I've mentioned the original text below the translated text to make it easier for Utopian Mods to verify the contribution. Also, you can count the paragraphs with my quoted text. Someone advised me to attach the screenshots of paragraphs but I believe that "Quoted Text" is much easier and sensible than taking screenshots of every paragraph and then uploading them because that will be painful for me. The preparation of "Quoted Text" already eats a lot of time.

Here is the link of original whitepaper (from Page 20 to 22): STEEM Whitepaper

---

So, that's all for today. I hope that you liked the contribution. If you have any suggestion to improve something, then please do not hesitate to let me know. I'll be more than willing to consider your suggestions. Thank you for spending your valuable time with me. If you've enjoyed the contribution, then make sure to support in any way you wish. Don't forget to follow me at @princewahaj for more updates. I'm also running three series: SEO Tutorial Series, The Weird Series and How-To Series. I am sure that you'll love them.

---

Posted on Utopian.io - Rewarding Open Source Contributors

---